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.
Expanded Definition
Sealed Secrets is a Kubernetes pattern for storing encrypted secret material in Git while deferring decryption to a controller running in the target cluster. In practice, it lets teams keep a Secret manifest in version control without committing plaintext, which supports GitOps workflows where desired state is reviewed, merged, and deployed through the same pipeline as application code.
The important distinction is that Sealed Secrets is not a full secrets management platform. It protects the payload at rest in Git, but it does not replace cluster-scoped key governance, rotation discipline, or broader access controls around who can seal, unseal, and deploy objects. Definitions vary across vendors and teams, but in NHI operations the term usually refers to the encrypted object, the controller, and the workflow that binds them together. For broader context on secret exposure patterns, see the OWASP Non-Human Identity Top 10.
The most common misapplication is treating Sealed Secrets as equivalent to secret elimination, which occurs when teams assume encryption in Git removes the need for lifecycle control, access review, and blast-radius planning.
Examples and Use Cases
Implementing Sealed Secrets rigorously often introduces operational friction, because every secret change requires resealing for the correct cluster scope and careful handling of controller keys, forcing teams to balance Git visibility against deployment overhead.
- A platform team commits sealed application credentials to a GitOps repository so pull requests can be reviewed without exposing plaintext values.
- A multi-cluster environment uses separate sealing scopes so a Secret encrypted for staging cannot be decrypted in production.
- An incident response team rotates a database password, then reseals the updated Secret before the next deployment sync.
- A security team audits whether cluster private keys are isolated and backed up, because controller compromise would expose any object sealed to that scope.
- A supply chain review checks whether automation accidentally reseals stale credentials into new manifests after application changes.
GitOps-focused teams often pair this pattern with guidance from the Guide to the Secret Sprawl Challenge when they need to reduce ad hoc secret handling across repositories. For deployment hygiene and failure analysis, the CI/CD pipeline exploitation case study is also relevant because sealed secrets still travel through build and delivery paths that attackers target.
Why It Matters in NHI Security
Sealed Secrets matters because it reduces one class of exposure without eliminating the underlying NHI risk. A sealed object still represents a credential, token, or key material path that can be abused if the sealing controller, cluster access, or Git workflow is compromised. That is especially important in environments where non-human identities outnumber human operators and where secrets drift across repositories, pipelines, and clusters.
NHIMG research shows the scale of the problem: 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation. In other words, encryption in Git can lower accidental exposure, but it does not solve stale credentials, untracked copies, or overbroad cluster permissions. The Shai Hulud npm malware campaign and the Reviewdog GitHub Action supply chain attack show how quickly secret exposure becomes a broader identity problem once automation is involved.
Organisations typically encounter the operational limits of Sealed Secrets only after a compromised controller, leaked private key, or failed rotation leaves an exposed secret unusable or already abused, at which point resealing and revocation become unavoidable.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secret management risks, including exposure in repositories and delivery pipelines. |
| OWASP Agentic AI Top 10 | Agentic workflows often manipulate secrets during deployment and automation. | |
| NIST CSF 2.0 | PR.AA-01 | Identity proofing and authentication govern who may create or deploy protected secret material. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust limits blast radius when cluster or pipeline trust is broken. |
| NIST AI RMF | AI systems often depend on secrets that must be governed across their lifecycle. |
Treat sealed objects as sensitive secrets and enforce storage, rotation, and access controls around them.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 1, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
