Why do large Kubernetes environments often outgrow Sealed Secrets for secrets management?

Why Large Kubernetes Clusters Outgrow Sealed Secrets

Sealed Secrets is a solid fit for small GitOps workflows because it keeps encrypted secret material in Git and lets a controller decrypt it inside the target cluster. The problem starts when a Kubernetes estate becomes operationally dense: more clusters, more namespaces, more teams, and more rotation events. At that point, the model shifts from simple encryption to repeated re-encryption, controller key management, and careful handling of who can seal what, where, and when.

That scale problem is not abstract. NHIMG’s Guide to the Secret Sprawl Challenge describes how fragmentation undermines central control, and the broader State of Secrets in AppSec research reports an average of 6 distinct secrets manager instances per organisation. Once that kind of sprawl appears, Sealed Secrets often becomes one more operational layer rather than a governance control.

In practice, security teams usually notice the strain only after repeated secret changes, cluster rebuilds, or access reviews have already turned routine work into a manual exception process.

How It Works in Practice

Sealed Secrets encrypts a secret object so it can be stored safely in source control, then relies on a controller running in the destination cluster to decrypt it into a native Kubernetes Secret. This is effective when the number of clusters and secrets is small, and when the same team controls both Git and cluster operations. As soon as those conditions change, the operational model becomes harder to sustain.

The main friction points are predictable. Controller private keys must be protected and rotated. Re-encryption is required when cluster keys change or when a secret is updated. Access becomes cluster-scoped rather than centrally policy-driven, which makes approvals and audit trails harder to standardise. Teams also spend time coordinating who can seal objects for which cluster, especially when multiple environments share similar manifests.

• Rotation is manual unless an external process is added around the controller.
• Each cluster needs its own trust boundary and key lifecycle management.
• Change visibility is limited because decryption happens at apply time, not in a central control plane.
• Large estates often need policy, approval, and audit consistency that encrypted manifests alone do not provide.

For teams looking at broader governance, the OWASP Non-Human Identity Top 10 is useful for understanding how machine-to-machine credentials fail when lifecycle, rotation, and accountability are weak. NIST’s Cybersecurity Framework 2.0 is also relevant because it pushes teams toward centralized identification, protection, and continuous oversight rather than ad hoc cluster-by-cluster handling.

These controls tend to break down when dozens of clusters each maintain separate sealing keys and release pipelines, because the re-encryption burden grows faster than the operational team can review it.

Where Sealed Secrets Becomes a Bad Fit

Tighter secret handling often increases operational overhead, so organisations have to balance Git-native convenience against governance, rotation speed, and scale. That tradeoff becomes visible in environments with frequent ephemeral cluster creation, multi-tenant platform teams, or regulated workloads that need strong segregation and auditable change control.

There is no universal standard that says Sealed Secrets is obsolete, but current guidance suggests it is best viewed as a delivery mechanism, not a full secrets governance platform. It works best when secret lifecycle events are infrequent and the trust boundary is stable. It struggles when large Kubernetes estates need central policy, delegated administration, and low-friction rotation across many namespaces and clusters.

This is why many organisations move toward external secrets platforms: they centralize source-of-truth management, reduce repeated re-encryption, and make audit and revocation easier to track. For teams evaluating the migration path, NHIMG’s Ultimate Guide to NHIs — Static vs Dynamic Secrets is a practical reference point for understanding why short-lived, centrally governed credentials often scale better than static encrypted blobs in Git.

In large clusters with frequent secret turnover and cross-team ownership, Sealed Secrets often stops being the control plane and becomes the bottleneck.

Related resources from NHI Mgmt Group

• Why do secrets create disproportionate risk in NHI environments?
• Why do native Kubernetes secrets controls fail in large environments?
• What are the best practices for reducing application access token theft in cloud and Kubernetes environments?
• How should teams reduce the risk from exposed NHI secrets?