Sealed Secrets
Encrypt Kubernetes Secrets into SealedSecrets that are safe to store in Git, decrypted only by a controller in your cluster.
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.
