First, let’s delete the database-credentials Secret and Pod resources that was created 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 pod pod-variable pod-volume -n octank kubectl delete secret database-credentials -n octank kubectl get secret -n octank
Now, let’s reuse the Secret created previously to create SealedSecret YAML manifests with kubeseal.
cd ~/environment/secrets 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 -n kube-system sealed-secrets-controller-7bdbc75d47-5wxvf
Verfiy that the database-credentials Secret unsealed from the SealedSecret was deployed by the controller to the octank namespace.
kubectl get secret -n octank database-credentials
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 apply -f pod-variable.yaml kubectl wait -n octank pod/pod-variable --for=condition=Ready kubectl logs -n octank pod-variable
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.