What breaks when Kubernetes secrets are stored in a vault but access tokens are overprivileged?

Why This Matters for Security Teams

Storing Kubernetes secrets in a vault is only half the control. If the pod, sidecar, or operator gets an overprivileged token, the vault becomes a high-value relay rather than a protection boundary. That is where lateral movement starts: one compromised workload can enumerate secrets, pull credentials for unrelated services, and expand access far beyond the original namespace. The real failure is authorization, not encryption.

This is why NHI governance treats workload tokens as first-class security assets. The OWASP Non-Human Identity Top 10 emphasizes that mis-scoped machine identities are often more dangerous than the secrets they retrieve. NHI Management Group’s Guide to the Secret Sprawl Challenge shows why secret storage alone does not solve sprawl when access paths remain broad. In practice, many security teams encounter the breach after a token is reused across services, not through intentional vault compromise.

How It Works in Practice

A vault can protect secrets at rest, but Kubernetes still needs a workload identity to request them. If that identity is backed by a broad service account token, the pod can retrieve every secret in its policy scope, even if the application only needs one database password. The result is a many-to-one trust problem: the vault validates the caller, but it cannot tell whether the caller is acting within its intended business function.

Current guidance suggests pairing vault storage with tightly scoped workload identity, short-lived credentials, and policy evaluated at request time. That means:

• Issuing tokens per workload, not per cluster.
• Limiting secret access to a specific namespace, application, or path.
• Using short TTLs and automatic revocation after task completion.
• Separating read access from list or enumerate permissions.
• Binding tokens to workload identity claims rather than static node-level trust.

The operational model is strongest when aligned to zero standing privilege and runtime authorization, not pre-created entitlements. NHI Management Group’s Ultimate Guide to NHIs — Static vs Dynamic Secrets explains why dynamic secrets reduce exposure windows, while the 2025 State of NHIs and Secrets in Cybersecurity reports that 60% of NHIs are overused, which is exactly the pattern that turns one token into many. The NIST AI Risk Management Framework is not Kubernetes-specific, but its emphasis on governance and measurable risk is useful when access decisions must be continuously justified. These controls tend to break down when teams reuse the same service account across multiple workloads because the token’s blast radius becomes impossible to contain.

Common Variations and Edge Cases

Tighter token scoping often increases operational overhead, requiring teams to balance faster deployment pipelines against stricter identity design. That tradeoff is real in multi-tenant clusters, legacy workloads, and platform teams that rely on shared ingress controllers or batch jobs.

There is no universal standard for this yet, but current guidance suggests treating the following as high-risk exceptions:

• Controllers that need broad read access for reconciliation, but should not inherit secret retrieval rights for application pods.
• Legacy applications that cannot consume short-lived tokens and still depend on static credentials.
• GitOps or CI/CD systems that mount cluster-wide tokens during deployment and accidentally inherit runtime secret access.
• Namespace sharing patterns where one service account is reused across multiple apps, breaking separation of duties.

For these environments, reduce scope first, then add compensating controls such as frequent rotation, explicit deny rules, and secret path partitioning. The CI/CD pipeline exploitation case study shows how pipeline identities become privileged choke points when they can reach too many secrets, and OWASP’s Non-Human Identity Top 10 is clear that overprivileged machine access is a governance issue, not just an implementation bug. In practice, the pattern fails most often when a single token must serve both deployment automation and runtime secret retrieval, because those trust models are not equivalent.

Related resources from NHI Mgmt Group

• What breaks when NHI secrets are stored in code or CI/CD systems?
• What breaks when JIT access is implemented without secrets visibility?
• What breaks when secrets are embedded in browser code?
• What breaks when organisations rely on standing access for high-risk roles?