How do Sealed Secrets enable GitOps for secrets?

What's really being asked

Whether you understand how asymmetric encryption lets you keep secrets in version control safely, and how that fits a declarative GitOps model where Git is the source of truth.

The full answer

A cluster-side Sealed Secrets controller generates an asymmetric key pair and keeps the private key inside the cluster. Developers use the kubeseal client, which fetches the controller's public certificate, to encrypt an ordinary Secret into a SealedSecret custom resource. Encryption is one-way with the public key, so the resulting SealedSecret is opaque and can be committed to Git, even a public repository, without exposing the data. A GitOps tool like Argo CD or Flux applies the SealedSecret to the cluster; the controller watches for it, decrypts it with its private key, and creates the corresponding native Secret in the right namespace. Sealing is scoped, typically to a namespace and name, so a SealedSecret cannot be moved elsewhere to be decrypted. This keeps the entire desired state, including secrets, declarative and reviewable in Git.

The mistakes people make

Claiming the encryption is symmetric or that anyone with kubeseal can decrypt. Forgetting that the private key lives only in the cluster and must be backed up. Thinking you commit the plaintext Secret. Ignoring the namespace/name scoping that prevents reuse elsewhere.

What usually comes next

How do you back up and rotate the controller's private key? What happens to SealedSecrets if you rebuild the cluster? How does scope-mode strict, namespace-wide, or cluster-wide affect portability? How does this compare to External Secrets or Vault?

A concrete example

kubeseal --format yaml < secret.yaml > sealedsecret.yaml encrypts db-creds with the controller's public key; you commit sealedsecret.yaml to a public repo, Flux applies it, and the controller decrypts it into the live db-creds Secret in the target namespace.