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 Secret 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 Secret objects.

Availability​

Sealed Secrets are available as standard with nine Managed GKE.

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)​

The easiest way to create a strict scoped Sealed Secret is to use our generator on runway.

  1. Generate a new Sealed Secret by filling out the form in the Secrets Generator Tab.

  2. Download the Sealed Secret.

  3. Apply it via kubectl.

    $ kubectl apply -f ~/Downloads/cloudsql-prod.yaml
    sealedsecret.bitnami.com/cloudsql-prod created

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

    $ kubectl get secret cloudsql-prod --template={{.data.password}} | base64 -d
    s#g{eJJ#O)p~VCHVNt26*WGD3

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

$ kubectl delete sealedsecret cloudsql-prod
sealedsecret.bitnami.com "cloudsql-prod" deleted

Note that in a production scenario we do not recommend you to apply the Sealed Secret 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 quite similar to the case of strict scope. However, our runway generator tool will not work here. In order to create a cluster-wide Sealed Secret, 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 to encrypt secrets locally.

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

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

  2. Use kubeseal to generate an encrypted SealedSecret resource.

    Note that you need to pass --scope cluster-wide to kubeseal CLI (or use annotations).

    Please refer to the Cluster login documentation to learn how to get your <project-number>.

    $ kubeseal --cert https://sealed-secrets.apps.<project-number>.ninegcp.ch/v1/cert.pem --scope cluster-wide < secret.yaml > sealed-secret.json

  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