Skip to main content

Sealed Secrets

Sealed Secrets encrypts Kubernetes Secrets so you can store them in git without any worries.

Details​

Usually the content of Kubernetes Secrets definitions is unencrypted which means it is not recommended to store them alongside other Kubernetes definitions in version control or anywhere that is not a secured environment. This adds manual and error-prone steps to your application deployment. As a solution to this, we are running a controller that will take care of decrypting your Sealed Secrets and turning them into normal Secrets objects.

Availability​

Sealed Secrets is available as an optional service for NKE. It can be deployed on an existing NKE cluster using Cockpit.

Scopes​

The Scope is nothing but the context of a sealed secret within a Kubernetes cluster. The Scope of a Sealed Secret relates to where and how the Sealed Secret can be decrypted and used within your cluster.

These are the possible Scopes:

  • strict (default): the secret must be sealed with exactly the same name and namespace. These attributes become part of the encrypted data and thus changing name and/or namespace would lead to a decryption error.
  • namespace-wide: you can freely rename the Sealed Secret within a given namespace.
  • cluster-wide: the secret can be unsealed in any namespace and can be given any name.

By default, strict Scope is selected unless you pass the --scope flag to kubeseal CLI with a different value.

It's also possible to request a Scope via annotations in the input secret you pass to kubeseal. Please refer to Scopes documentaion for more details.

Usage​

Strict Scope (default)​

In order to use sealed-secrets, you need to install the CLI-utility kubeseal which is part of the sealed-secrets project. After you installed kubeseal for your OS you can start do encrypt secrets locally.

  1. Define your normal unencrypted secret in a local file named secret.yaml.

    apiVersion: v1
    kind: Secret
    metadata:
      name: example
      namespace: dev
    type: Opaque
    stringData:
      password: verysecure

  2. Use kubeseal to generate an encrypted SealedSecret resource.

    $ kubeseal --controller-namespace nine-system < secret.yaml > sealed-secret.json

    Note: the current kube context needs to be set to the NKE cluster, alternatively the kubeconfig and context can be provided with additional options to kubeseal.

  3. Apply it via kubectl.

    $ kubectl apply -f sealed-secret.json
    sealedsecret.bitnami.com/example created

  4. Read back the Secret resource that the controller created for us.

    $ kubectl get secret example -o jsonpath='{.data.password}' | base64 -d
    verysecure

To delete the Secret again, you can just delete the SealedSecret and the controller will also remove the Secret object.

$ kubectl delete sealedsecret example
sealedsecret.bitnami.com "example" deleted

Note that in a production scenario we do not recommend you to apply the SealedSecret locally with kubectl, but instead store it in your configuration repository and let Argo CD take care of creating it.

Cluster-wide Scope​

The procedure is exactly the same as in the case of the Strict Scope. Just pass --scope cluster-wide to kubeseal CLI (or use annotations).

$ kubeseal --scope cluster-wide --controller-namespace nine-system < secret.yaml > sealed-secret.json