Sealed Secrets: Safely Commit K8s Secrets to Git

WHY IT EXISTS Storing plain-text Kubernetes Secrets in Git is a major security risk, but not storing them breaks the GitOps model where Git is the single source of truth. This forces teams to manage secrets out-of-band, creating operational complexity and a separate workflow from other configuration.

THE MENTAL MODEL Think of Sealed Secrets as a public mailbox for your Kubernetes cluster. Anyone with the cluster's public key (the address) can put an encrypted letter (a Secret) into the box. But only the cluster, which holds the private key, can open the box and read the letter. The encrypted letter itself, the SealedSecret, is safe to pass around anywhere, even in a public repository.

HOW IT WORKS A controller installed in your Kubernetes cluster generates a public/private key pair. The private key never leaves the cluster. Developers use the kubeseal command-line tool and the controller's public key to encrypt a standard Kubernetes Secret manifest into a SealedSecret custom resource. This SealedSecret is then committed to Git. When a GitOps tool like Argo CD or Flux applies this manifest, the Sealed Secrets controller recognizes it, decrypts the data using its private key, and creates a standard Kubernetes Secret resource in the cluster.

WHEN TO USE IT Use Sealed Secrets when you are committed to a GitOps workflow and need a simple, self-contained way to manage secrets in Git without external dependencies. It's ideal for teams that want to keep their entire application and infrastructure configuration, including secrets, in one version-controlled place.

WHEN NOT TO USE IT Avoid Sealed Secrets if you require advanced features like dynamic secrets, automatic rotation, or detailed audit logs, which are better handled by dedicated systems like HashiCorp Vault or AWS Secrets Manager. If your security policy forbids storing any form of secret, even encrypted, in Git, this solution is not compliant.

ONE CANONICAL EXAMPLE A developer needs to provide a database password to an application. They create a standard Secret.yaml file locally. They run kubeseal --format yaml < secret.yaml > sealed-secret.yaml. The resulting sealed-secret.yaml contains encrypted data and is safe to commit to the team's public GitHub repository. The CI/CD pipeline applies this manifest, and the in-cluster controller creates the plain-text Secret for the application to use. The original secret.yaml is never committed.