Sealing Your Secrets

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

Output: 


NAME                  TYPE                                  DATA   AGE
default-token-gv8nr   kubernetes.io/service-account-token   3      2d23h

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 : 


apiVersion: v1
data:
  password: VHJ1NXROMCE=
  username: YWRtaW4=
kind: Secret
metadata:
  name: database-credentials
  namespace: octank
type: Opaque

Output of sealed-secret.yaml: 


apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  creationTimestamp: null
  name: database-credentials
  namespace: octank
spec:
  encryptedData:
    password: AgBR2S0Orv6YKLgEboBbPBsV6PX9gP9gUUTrISv(...)daQtadX6XnFqoYwOQ==
    username: AgBtkiM4Q7w3kesVDbZgKOpiVQ+9XMmlqr9xABf(...)B9quqLBF80QFSsZpQ==
  template:
    data: null
    metadata:
      creationTimestamp: null
      name: database-credentials
      namespace: octank
    type: Opaque

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

Output: 


(...)
2021/07/14 21:27:01 HTTP server serving on :8080
2021/07/15 13:22:20 Updating octank/database-credentials
2021/07/15 13:22:20 Event(v1.ObjectReference{Kind:"SealedSecret", Namespace:"octank", Name:"database-credentials", UID:"abc9b6ab-fe69-453a-8654-c9593de935c7", APIVersion:"bitnami.com/v1alpha1", ResourceVersion:"104915", FieldPath:""}): type: 'Normal' reason: 'Unsealed' SealedSecret unsealed successfully

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

Output: 


NAME                   TYPE     DATA   AGE
database-credentials   Opaque   2      90s

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

Output: 


pod/pod-variable created
pod/pod-variable condition met
DATABASE_USER = admin
DATABASE_PASSWROD = Tru5tN0!

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.