What is the difference between keeping secrets in Sealed Secrets and using an external secrets manager with GitOps?

Sealed Secrets stores encrypted secret material alongside code and decrypts it inside the cluster, while an external secrets manager keeps the secret value out of Git and stores only a reference in the repository. The latter adds central access control, audit logs, and dynamic updates, but it also introduces an external dependency that must be governed and available.

Why This Matters for Security Teams

Sealed Secrets and external secrets managers both aim to reduce the blast radius of secret exposure, but they shift risk in different places. With Sealed Secrets, the encrypted payload lives in Git and the cluster becomes the decryption boundary. With an external manager, Git stores intent while the secret value remains centralized elsewhere, which usually improves auditability and rotation control. The practical question is not which pattern is “more secure” in the abstract, but which trust boundary matches the delivery model and operational discipline.

That distinction matters because secret exposure rarely happens in isolation. The State of Secrets Sprawl 2025 shows how often secrets leak into code and related systems, which is why teams are increasingly treating secret storage as a lifecycle problem rather than a one-time encryption decision. NIST also frames this as a governance issue across identify, protect, detect, and recover, not just a storage mechanism choice, in the NIST Cybersecurity Framework 2.0. In practice, many security teams discover the real weakness only after a repo, cluster, or pipeline has already been granted too much trust.

How It Works in Practice

Sealed Secrets encrypts secret material so it can be committed safely, then the controller in the cluster decrypts it at apply time. That makes GitOps workflows simple because the repository still contains the deployable object, and drift detection can treat the secret like any other managed manifest. The tradeoff is that the cluster now holds the decryption capability, so cluster compromise becomes a higher-value event.

External secrets managers invert the model. Git stores a reference to a secret name, path, or key identifier, and the workload fetches the secret at runtime through the manager or an operator. This supports centralized policy, secret versioning, audit logs, and rotation without changing the repository. It also aligns better with the principle that the secret value should never be copied into code history.

In operational terms, teams usually evaluate three things:

• Who can decrypt or retrieve the secret at runtime.
• Whether secret rotation should happen independently of application deployments.
• How much dependency on the cluster, controller, or external service the business can tolerate.

For GitOps teams, the external-manager pattern is often the cleaner control plane because it keeps the repository declarative while moving secret custody into a purpose-built system. The Guide to the Secret Sprawl Challenge is useful context here, because the underlying problem is usually uncontrolled distribution, not merely storage format. OWASP’s OWASP Non-Human Identity Top 10 is also relevant when controllers, sync agents, and CI/CD systems become the real consumers of those secrets. These controls tend to break down when teams assume the cluster will always be trusted and highly available, because secret retrieval, renewal, and audit failures then cascade into deployment outages.

Common Variations and Edge Cases

Tighter secret centralization often increases operational coupling, requiring organisations to balance stronger governance against dependency risk. That tradeoff becomes visible in environments that need offline deployments, air-gapped clusters, or very fast recovery from control-plane failure.

Best practice is evolving, but a few patterns are already clear. Sealed Secrets can be acceptable when teams want portable encrypted manifests, limited operational overhead, and a narrower problem scope. External secret managers are usually stronger when rotation frequency, auditability, and cross-environment consistency matter more than local simplicity. There is no universal standard for this yet, but mature teams usually avoid hardcoding secret values in any form and instead treat Git as a control plane, not a vault.

Two edge cases deserve special attention. First, if the external manager becomes unavailable, application startup and redeployments may fail unless the platform has a defined fallback, caching, or fail-open policy, and that policy must be explicit. Second, if Sealed Secrets is used to protect highly sensitive material, the security of the cluster controller, RBAC, and admission path becomes just as important as the encryption itself. The Ultimate Guide to NHIs — Static vs Dynamic Secrets helps frame why short-lived, centrally governed secrets are often preferred when workloads change frequently. In practice, teams usually confront the limits of either approach only after a failed rotation, an unavailable manager, or a cluster incident reveals where the real trust boundary was.

Related resources from NHI Mgmt Group

• How should teams migrate from Sealed Secrets to an external secrets manager in Kubernetes GitOps workflows?
• What is the difference between repository-based discovery and external attack surface discovery for DAST programs?
• What is the difference between privilege reduction and secret rotation?
• What is the difference between a rules-based secret scanner and a hybrid scanner?