Sealed Secrets
Encrypt Kubernetes Secrets into SealedSecrets that are safe to store in Git, decrypted only by a controller in your cluster.
Open source alternative to:
Sealed Secrets is an open source tool originally created by Bitnami that solves a common Kubernetes problem: you can keep all your cluster configuration in Git, except Secrets. It consists of two parts — a controller that runs inside your cluster and a command-line tool called kubeseal. Together they let you encrypt a Kubernetes Secret into a SealedSecret custom resource that is safe to commit, even to a public repository. Only the controller running in the target cluster holds the private key needed to decrypt it; not even the original author can recover the secret from the sealed file.
kubeseal uses asymmetric cryptography: the controller generates an RSA key pair (4096-bit by default) stored as a Kubernetes Secret and publishes the public certificate for encrypting. Secret data is encrypted with a single-use AES-256-GCM session key that is encapsulated with the cluster's public key using RSA-OAEP with SHA-256. Sealing keys are renewed automatically every 30 days, and old keys are retained so existing SealedSecrets keep decrypting. The controller watches for SealedSecret resources and turns them into standard Secrets that work with any workload — plain kubectl, Helm, Argo CD, and Flux. Scopes (strict, namespace-wide, cluster-wide) control how tightly a sealed secret is bound to a name and namespace.
Compared with running a dedicated secrets platform such as HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or Doppler, Sealed Secrets is a much lighter-weight and fully free approach built around the GitOps workflow: encrypted secrets live next to your code and roll out with your normal deploy pipeline. The trade-offs are that it does not offer dynamic secrets, leases, a management UI, or central audit trails, and you remain responsible for rotating your actual secret values. Installation is a single YAML manifest or the official Helm chart on any Kubernetes cluster.
Frequently Asked Questions
Which platforms does Sealed Secrets run on?
The controller runs inside any Kubernetes cluster — self-managed, EKS, GKE, AKS, OpenShift, Minikube, or Kind — installed with a single YAML manifest or the official Helm chart. The kubeseal CLI ships as binaries for Linux, macOS, and Windows, and is also available through Homebrew, MacPorts, and Nixpkgs.
Can I decrypt a SealedSecret without the cluster?
Not by default. The private keys exist only inside the cluster unless you back them up. If you have a key backup, the kubeseal --recovery-unseal --recovery-private-key command can decrypt sealed secrets offline. With no key backup and no access to the cluster, sealed secrets cannot be recovered and you need to reissue the underlying credentials.
How does key rotation work?
The controller generates a new sealing key every 30 days and keeps old keys so previously sealed secrets continue to decrypt. You can re-encrypt committed SealedSecrets with kubeseal --re-encrypt, force an early renewal with the --key-cutoff-time flag if a key is compromised, and back up all sealing keys with kubectl. Key renewal does not replace rotating your actual secret values.
Does Sealed Secrets work with GitOps tools like Argo CD and Flux?
Yes. The controller continuously watches for SealedSecret resources and produces regular Kubernetes Secrets, so any tool that applies manifests — kubectl, Argo CD, Flux, or Helm — works with it. Because encrypted SealedSecrets are safe to commit even to public repositories, they can travel through the same GitOps pipeline as the rest of your configuration.
What encryption does Sealed Secrets use?
Secrets are encrypted with a single-use 32-byte AES-256-GCM session key, and that session key is encapsulated with the controller's RSA public key using RSA-OAEP with SHA-256. Keys are managed as X.509 certificates from a 4096-bit RSA key pair by default, renewed every 30 days with a ten-year validity span, and you can bring your own certificates.