Kubernetes Sealed Secrets: Git-Friendly Secret Management

WHY IT EXISTS Standard Kubernetes Secrets are only base64 encoded, not encrypted, making them unsafe to store in a Git repository. This forces teams to manage secrets outside of their main configuration, breaking the declarative GitOps model. Sealed Secrets was created to allow secrets to be managed in Git like any other resource.

THE MENTAL MODEL Think of a public mailbox with a special lock. Anyone can see the mailbox and its slot (the public key) and create a package (an encrypted Secret) that fits. They can then drop this package (the SealedSecret custom resource) into the mailbox (your Git repo). However, only the mail carrier (the Sealed Secrets controller in your cluster) has the unique physical key (the private key) to open the packages and deliver the mail (the decrypted Kubernetes Secret) to your applications.

HOW IT WORKS A controller runs in your Kubernetes cluster and generates a public/private key pair. The private key never leaves the cluster. Developers fetch the public key and use a CLI tool called kubeseal to encrypt a standard Kubernetes Secret manifest. This process creates a new manifest for a SealedSecret custom resource. This encrypted manifest is safe to commit to Git. When the SealedSecret is applied to the cluster, the controller detects it, decrypts the data using its private key, and creates a regular Kubernetes Secret that your pods can use.

WHEN TO USE IT Use Sealed Secrets when you practice GitOps and want a single source of truth for all your Kubernetes manifests, including secrets. It's ideal for CI/CD pipelines that automate the deployment of applications requiring credentials, API keys, or certificates, as the encrypted secrets can live alongside the application code and configuration.

WHEN NOT TO USE IT Do not use Sealed Secrets if you need to recover the original secret value outside the cluster. Once sealed, a secret can only be decrypted by the specific controller that holds the private key. If that key is lost (e.g., the cluster is destroyed without a backup), the sealed secrets are permanently unusable. It is also less ideal for systems that require dynamic, short-lived secrets, which are better handled by a dedicated secrets manager like HashiCorp Vault.

ONE CANONICAL EXAMPLE A developer creates a standard Secret YAML for a database password. They run the kubeseal command against this file: kubeseal < db-secret.yaml > sealed-db-secret.yaml. The output file, sealed-db-secret.yaml, contains the encrypted password and is safe to commit to a public GitHub repository. A GitOps tool like ArgoCD applies this manifest, and the Sealed Secrets controller in the cluster automatically creates the usable, decrypted db-secret for the application.