Sealed Secrets

Sealed Secrets solves the GitOps secret problem: if everything is in Git, where do secrets go? You cannot commit plaintext secrets to Git. Sealed Secrets encrypts them with the controller’s public certificate, and only the controller’s private key, which stays in the cluster, can decrypt them.

How it works

There are two parts: a controller that runs in the cluster, and kubeseal, a client-side CLI. The CLI uses asymmetric encryption. It encrypts a normal Secret manifest into a SealedSecret using the controller’s public certificate. You commit the SealedSecret to Git, ArgoCD or Flux applies it, and the controller unseals it into an ordinary Secret with the same name and namespace.

By default the scope is strict: the name and namespace are part of the encrypted data, so a SealedSecret cannot be renamed or moved to another namespace and still decrypt. Namespace-wide and cluster-wide scopes relax this. The controller renews its sealing key every 30 days by default, adds the new key, and keeps old keys so existing SealedSecrets still decrypt.

A practical example

kubectl create secret generic mysecret --dry-run=client \
  --from-literal=password=changeme -o json > mysecret.json
kubeseal -f mysecret.json -w mysealedsecret.json
kubectl create -f mysealedsecret.json

The first command builds a Secret locally without sending it to the cluster, the second seals it, and the third applies it. For CI use, kubeseal --fetch-cert saves the public certificate so sealing can happen offline. By default the CLI expects the controller in kube-system under the name sealed-secrets-controller, so a Helm install with a different name needs --controller-name.

Common mistakes

• Not backing up the sealing keys. Without a backup of the private keys, SealedSecrets cannot be decrypted after losing the cluster. Repeat the backup after each key renewal.
• Treating key renewal as secret rotation. If a sealing key leaks, renew the key and also change the real credentials, then reseal.
• Using cluster-wide scope everywhere, which weakens the protection that comes from binding to a name and namespace.
• Committing the plain Secret manifest next to the sealed one.
• Forgetting that the unsealed result is a regular Kubernetes Secret, so RBAC still controls who can read it in the cluster.

When to use it and when not to

Sealed Secrets suits small to medium GitOps setups that want encrypted secrets in the same repository as their manifests, with little infrastructure. It is less suitable when you need central rotation, audit trails or dynamic credentials, where an external secrets manager such as HashiCorp Vault or a cloud secret store is a better fit. See ConfigMap and Secret for the underlying objects and our GitOps service for delivery pipelines.

See also

• GitOps
• ArgoCD
• ConfigMap and Secret
• RBAC