// the find
bitnami-labs/sealed-secrets
A Kubernetes controller and tool for one-way encrypted Secrets
Sealed Secrets solves the one glaring gap in GitOps: you can commit everything to git except Kubernetes Secrets. It works by running a controller in-cluster that holds the private key, while you encrypt secrets client-side with `kubeseal` using the public key. The result is a `SealedSecret` CRD that's safe to commit publicly because only your cluster can decrypt it.
The scope system (strict/namespace-wide/cluster-wide) is well thought out — namespace and secret name are baked into the ciphertext by default, so a stolen SealedSecret can't be replayed in another namespace or under a different name. Key rotation is automatic every 30 days but old keys are kept, so existing SealedSecrets never break on renewal. The `--merge-into` flag and raw mode make incremental updates workable without needing the plaintext of other keys in the same secret. Helm chart, Kustomize, and plain YAML manifests are all first-class installation paths.
The controller restart requirement after manually managing sealing keys is a real ops footgun — there's no hot-reload. If the cluster is gone and you didn't back up the sealing key secret, everything is unrecoverable; this is documented honestly but the backup story is still 'go grab a k8s Secret before disaster strikes'. The offline cert workflow is fragile in private GKE clusters and similar locked-down environments where `kubeseal` can't reach the API server — the workaround (download and ship the cert separately) adds process overhead. Scopes are still controlled via two separate annotations with a note that they'll be consolidated 'next release', which has apparently been pending for a while.