First, let’s delete the database-credentials Secret resource that was created with Kustomize earlier in this module and deployed to the octank namespace in the cluster. After this operation, the only Secret that should exist in that namespace will be that of the token generated by Kubernetes for the default service account associated with the octank namespace.
kubectl delete secret database-credentials -n octank
kubectl get secret -n octank
Output:
Now, create the Secret and SealedSecret YAML manifests with Kubectl, Kustomize and Kubeseal.
cd ~/environment/secrets
kubectl kustomize . > secret.yaml
kubeseal --format=yaml < secret.yaml > sealed-secret.yaml
An alternative approach is to fetch the public key from the controller and use it offline to seal your Secrets
kubeseal --fetch-cert > public-key-cert.pem
kubeseal --cert=public-key-cert.pem --format=yaml < secret.yaml > sealed-secret.yaml
View the contents of the regular Secret and the corresponding SealedSecret with the following commands:
cat secret.yaml
cat sealed-secret.yaml
Output of secret.yaml :
Output of sealed-secret.yaml:
Note that the keys in the original Secret, namely, username and password, are not encrypted in the SealedSecret; only their values. You may change the names of these keys, if necessary, in the SealedSecret YAML file and still be able to deploy it successfully to the cluster. However, you cannot change the name and namespace of the SealedSecret. The SealedSecret and Secret must have the same namespace and name
Now, deploy the SealedSecret to your cluster:
kubectl apply -f sealed-secret.yaml
Looking at the logs of the contoller, you can see that it picks up the SealedSecret custom resource that was just deployed, unseals it to create a regular Secret.
kubectl logs sealed-secrets-controller-84fcdcd5fd-9qb5j -n kube-system
Output:
Verfiy that the database-credentials Secret unsealed from the SealedSecret was deployed by the controller to the octank namespace.
kubectl get Secret database-credentials -n octank
Redeploy the pod that reads from the above Secret and verify that the keys have been exposed as environment variables with the correct literal values.
kubectl delete pod pod-variable -n octank
kubectl apply -f pod-variable.yaml -n octank
kubectl logs pod-variable -n octank
Output:
The YAML file, sealed-secret.yaml, that pertains to the SealedSecret is safe to be stored in a Git repository along with YAML manifests pertaining to other Kubernetes resources such as DaemonSets, Deployments, ConfigMaps etc. deployed in the cluster. You can then use a GitOps workflow to manage the deployment of these resources to your cluster. The YAML file, secret.yaml, that pertains to the Secret may be deleted because it is never used in any subsequent workflows.