Sealed Secrets is a Kubernetes approach for committing encrypted secret data to Git without exposing plaintext. A controller in the target cluster decrypts the sealed object into a normal Secret. The model is convenient for GitOps, but it still depends on careful key management, cluster scoping, and manual re sealing when application secrets change.
What Sealed Secrets Means in Practice
Sealed Secrets is best understood as a GitOps-friendly way to store Kubernetes secret material in encrypted form until the target cluster decrypts it. The value is operational convenience, not absolute secrecy: the object can live safely in Git, but the cluster-side controller, the sealing key, and the namespace and scope rules become part of the trust boundary.
That makes Sealed Secrets different from plain Kubernetes Secrets, where the main concern is whether the secret ever appears in plaintext outside the cluster. With Sealed Secrets, the real question becomes whether the encrypted object can only be opened by the intended controller in the intended cluster, and whether the workflow keeps pace with application changes and key rotation.
How Sealed Secrets Works with GitOps
A Sealed Secret is created from a normal secret value, then encrypted so the resulting manifest can be committed to source control. In the cluster, the controller reverses that process and creates a standard Kubernetes Secret for the application to consume. That lets teams treat secret delivery as part of the same declarative workflow they use for deployments, which is why it fits GitOps so naturally.
Its usefulness depends on scoping. Namespace-scoped and cluster-scoped sealed objects behave differently, and the wrong choice can make a manifest too reusable or too brittle. A tight GitOps workflow also means secret updates are not automatic when the underlying application secret changes, so re sealing becomes a normal part of the operational lifecycle rather than a one-time setup step.
For readers comparing secret patterns, the trade-off is similar to other GitOps secret approaches: convenience and reviewability improve, but the team still has to manage encryption keys, cluster trust, and the lifecycle of the secret data itself. NHIMG’s SOPS and Sealed Secrets guide compares those choices in a GitOps context.
Key Management, Scope, and Rotation Concerns
The strongest security property of Sealed Secrets is only as good as the private key held by the controller. If that key is exposed, the protection on every sealed object that depends on it is weakened, which is why backup, rotation, and recovery planning matter even when the Git history never contains plaintext. Scope also matters because the same sealed payload may be intentionally usable in one namespace but useless, or dangerously reusable, in another.
In practice, teams need to treat the controller key like other high-value secret material, with clear ownership and a rotation strategy. The model does not remove secret management work, it shifts it into key lifecycle management and repository hygiene, so changes to applications, namespaces, or cluster tenancy can require fresh sealing and validation. That is why broader secret handling guidance still applies, especially around rotation and exposure control.
Sealed Secrets also sits inside a larger Kubernetes secret surface that includes RBAC, encryption at rest, auditability, and alternative secret delivery mechanisms. Kubernetes Secrets Security Guide covers the surrounding controls, while Secrets Management Guide explains the lifecycle pressures that make re sealing and rotation necessary.
Operational Failure Modes and Common Misuse
Sealed Secrets fails most often when people assume encryption in Git is the same as end-to-end secrecy. It is not. The manifest is protected at rest in the repository, but the cluster still has to decrypt it, which means cluster access, controller trust, and namespace scoping all remain security-critical. If those assumptions are wrong, the system can give a false sense of safety while still exposing the application to compromise.
Another common failure mode is drift between the sealed object and the application’s needs. Teams may update the app, move it between environments, or rotate a credential elsewhere and forget to regenerate the sealed manifest. That creates deployment failures, stale credentials, or manual workarounds that push people toward unsafe exceptions such as sharing decrypted values outside the intended workflow.
Risk and Threat Considerations
Sealed Secrets reduces plaintext exposure in Git, but it concentrates trust into the cluster controller and its sealing key. If that controller, its key material, or the cluster boundary is compromised, an attacker can turn the encrypted repository artifact back into usable secret material and move from source control exposure to runtime access.
Failure mechanism: Weak key protection, overbroad scope, or compromised cluster access allows encrypted manifests to be decrypted or replayed outside their intended boundary.
Impact: Exposed credentials, service tokens, or application secrets can enable unauthorized access, lateral movement, or persistence, and may require immediate re sealing and rotation across dependent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Sealed Secrets depends on lifecycle control of sealing keys and secret material. |
| AC-6 — Least Privilege | Cluster-scoped decryption and secret access should be restricted to the minimum set of identities. | |
| SC-12 — Cryptographic Key Establishment and Management | The model’s security hinges on protecting and rotating the controller’s sealing keys. | |
| Recommendation — Manage controller keys and secret rotation under IA-5 to limit reuse and exposure. Apply AC-6 to restrict who and what can decrypt or retrieve sealed secret material. Use SC-12 to govern sealing key generation, storage, rotation, and recovery. | ||
| CIS Controls v8 | 5 — Account Management | Sealed Secret workflows depend on controlling which accounts can alter or consume secret material. |
| Recommendation — Restrict secret-admin accounts and revoke unused access paths under CIS Control 5. | ||
| OWASP ASVS | V14 — Data Protection | Encrypted secret manifests and secret handling are a data protection concern. |
| Recommendation — Use V14 to verify secrets are protected in storage, transport, and operational handling. | ||
Practitioner Guidance
Why practitioners should care: Sealed Secrets is a workflow control as much as a cryptographic one, so its security depends on how tightly the cluster key, namespace scope, and re sealing process are governed. Treat it as part of the secret lifecycle, not as a replacement for secret management.
What to watch for: Review whether the team knows who owns the controller key, how rotation is handled, and when a sealed manifest must be regenerated after application or environment changes. If those answers are unclear, the GitOps process is carrying hidden operational risk.
Practitioner takeaway: The safest Sealed Secrets deployments are the ones that keep the encryption boundary narrow and the re sealing process routine, documented, and owned.
Related resources from NHI Mgmt Group
- How should teams migrate from Sealed Secrets to an external secrets manager in Kubernetes GitOps workflows?
- Why do large Kubernetes environments often outgrow Sealed Secrets for secrets management?
- What are the signs that Sealed Secrets is becoming a bottleneck for secret rotation and auditability?
- What is the difference between keeping secrets in Sealed Secrets and using an external secrets manager with GitOps?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org