In a GitOps pipeline, a team wants to commit their Kubernetes Secret manifests directly into the same git repository that drives deployment (for example via Bitnami's 'Sealed Secrets' controller), including in a repo with broad read access. How can a Secret be safely committed to git, and what does this pattern protect against versus what does it not protect against?

## How the pattern works **Sealed Secrets** is a controller-based pattern: a controller deployed in-cluster generates and holds an **asymmetric key pair**, typically rotating it periodically, and publishes only the public half. From there: 1. A developer takes a plaintext Kubernetes Secret manifest and, instead of applying or committing it directly, runs it through the `kubeseal` CLI with that public key, producing a `SealedSecret` custom resource whose data is asymmetrically encrypted ciphertext. 2. This is what gets committed to git and applied through the normal GitOps pipeline, via ArgoCD or Flux syncing the repo. 3. When the SealedSecret manifest is applied to the cluster, the in-cluster controller — the only holder of the private key — decrypts it and materializes a standard Kubernetes Secret object, which the pod then consumes exactly as it would any other Secret. ## The GitOps tension it resolves This exists to resolve a real tension in GitOps. GitOps's core premise is that the git repo is the single declarative source of truth for everything running in the cluster, diffable and auditable via commit history and reviewable via pull request — but plaintext Secrets obviously cannot live safely in git, especially in repos with broad read access such as contractors, CI systems, or forks. Before this pattern, teams either - kept Secrets out of GitOps entirely, applying them manually through a separate, less-audited process and breaking the "everything is declared in git" property, - or used external secret references fetched at apply time from Vault or a cloud secrets manager, which keeps secrets fully out of git but adds a runtime dependency on that external system. Sealed Secrets threads the needle: the encrypted form CAN live in git, satisfying "declare everything", while the plaintext never touches git or any system other than the in-cluster controller. ## What it protects against This protects specifically against the threat of "anyone who can read this git repository's history can read the secret" — since only the private key inside the target cluster can decrypt a SealedSecret, someone who clones the repo, browses old commits, or even has admin access to the git hosting platform gains nothing usable from the ciphertext. - Each SealedSecret is also typically **scoped by default to a specific namespace and name**, so it can't be copy-pasted and reapplied elsewhere in the cluster without re-encryption. - It's also useful for **pull-request review workflows**: a reviewer can see that a secret changed, since a new SealedSecret was committed, and review everything else in the diff without ever seeing the plaintext value. ## What it does not protect against What it explicitly does NOT protect against matters just as much. - **The in-cluster runtime form.** Once the controller decrypts a SealedSecret into a live Kubernetes Secret object inside the cluster, that Secret is a completely ordinary, base64-only-encoded Secret from that point forward — anyone with RBAC permission to read secrets in that namespace, or anyone with access to unencrypted etcd storage, can read the plaintext exactly as with any other Secret. Sealed Secrets adds zero in-cluster protection beyond whatever Kubernetes' normal Secret mechanics already provide. - **Rotation, audit and expiry.** It also provides no rotation, no per-read audit trail, and no automatic expiry — the decrypted value is just as static and long-lived as a normal Secret, unlike a Vault-issued dynamic credential with a TTL and lease-based revocation. - **A compromised controller key.** And it protects nothing if the controller's private key itself is compromised, such as during a cluster compromise, since an attacker with that key can decrypt every SealedSecret ever committed to the repo's history. ## Failure modes in production A common real incident is the controller's private key being lost — for instance a cluster rebuilt without backing up the key — which makes every previously-committed SealedSecret in git permanently undecryptable, forcing every one to be regenerated from the original plaintext and re-sealed with a new key pair; this is why teams are told to back up the controller's key pair as carefully as any other root secret. Another common failure is engineers assuming "it's sealed, so it's fully safe" and relaxing RBAC or logging discipline on the resulting live Secret objects, forgetting the encryption only protects the git-at-rest form, not the in-cluster runtime form. ## The alternatives, and when to prefer them Bitnami's Sealed Secrets project is the most widely used implementation of this pattern, with alternatives including - **Mozilla SOPS**, for encrypting values in git more generally; - **the External Secrets Operator**, which instead syncs Secret values FROM Vault or a cloud secrets manager INTO Kubernetes at apply time, keeping plaintext out of git entirely by never storing it there in any form. A team with strict compliance requirements around credential rotation and per-access auditing, such as PCI-DSS scope, would typically prefer External Secrets Operator plus Vault over Sealed Secrets, precisely because Sealed Secrets solves "safe to commit ciphertext to git" but not "credentials rotate automatically and every read is audited" — a different, and for regulated workloads often more important, problem.