Kubernetes secrets need lifecycle controls beyond Vault choice

At a glance

What this is: This compares HashiCorp Vault and Azure Key Vault for Kubernetes secrets and finds that vault choice does not solve lifecycle exposure, overprivilege, or secret sprawl.

Why it matters: It matters because IAM, NHI, and platform teams still need controls for secret creation, access scope, revocation, and monitoring across Kubernetes and adjacent systems.

By the numbers:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28,65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.

👉 Read Entro Security's comparison of HashiCorp Vault and Azure Key Vault for Kubernetes secrets

Context

Kubernetes secrets management is a governance problem as much as a storage problem. A vault can reduce exposure, but it does not automatically solve who can use a secret, how long it stays valid, or whether it has already escaped into code, chat, or tickets.

For IAM and NHI teams, the practical question is whether the secret platform is only a repository or part of a full lifecycle control plane. The article frames Vault and Key Vault as stronger alternatives to native Kubernetes secrets, but both still depend on external monitoring, revocation discipline, and access scoping.

That is a typical enterprise problem, not an edge case. Most organisations now operate across clusters, cloud services, and collaboration tools, so secret governance has to follow the credential wherever it moves.

Key questions

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

A: The vault still stores data securely, but the access path becomes the weak point. A broad token can retrieve far more secrets than the workload actually needs, which turns one credential into many. That creates a large blast radius, weakens separation of duties, and makes revocation harder because the compromise is in authorization rather than storage.

Q: Why do Kubernetes secrets still create risk after teams move to Vault or Key Vault?

A: Because the vault solves storage, not the entire lifecycle. Secrets can still be duplicated, copied into chat or code, reused across apps, or left active after the workload changes. Without ownership, expiry, and revocation discipline, the vault becomes a better container for the same underlying governance problem.

Q: How do security teams know whether secret rotation is actually reducing exposure?

A: Look for shorter credential lifetimes, fewer reused secrets, and faster revocation when a token is exposed. If the same secret appears in multiple places, or if inactive credentials remain usable, rotation is not reducing risk. Effective programmes measure both discovery and invalidation, not just the number of rotations completed.

Q: Who should own secret revocation when Kubernetes spans multiple clouds and teams?

A: Ownership should sit with the team that controls the workload and the secret policy, not with whichever platform happened to store the credential last. In practice that means central policy with delegated execution, so revocation can happen consistently across Azure, Kubernetes, and adjacent collaboration tools.

Technical breakdown

Why Kubernetes native secrets create governance blind spots

Kubernetes native secrets are limited because they are primarily cluster-scoped storage, not a full identity governance layer. They can reduce convenience friction, but they do not by themselves establish provenance, contextual risk, or cross-system lifecycle control. When secrets are copied into manifests, chat, tickets, or code, the secret becomes an NHI asset with an uncontrolled distribution path. The technical issue is not encryption alone. It is that encrypted storage inside the cluster still leaves access, duplication, and revocation questions unresolved across the wider delivery pipeline.

Practical implication: treat cluster secrets as one control point, not the control plane for secret governance.

How HashiCorp Vault changes secret issuance

Vault shifts the model from static credential storage to controlled issuance, including temporary credentials for supported systems. That improves the security posture when the consumer can authenticate cleanly and the credential can expire on use or on timeout. But the protection only holds if the access token to Vault is itself tightly scoped, monitored, and rotated. Once a broad Vault token is exposed, the encryption layer offers little protection because the attacker is operating through legitimate authorization rather than breaking crypto.

Practical implication: constrain Vault tokens as aggressively as the secrets they unlock.

Why Azure Key Vault fits some Kubernetes estates better than others

Azure Key Vault works well when the surrounding estate is Azure-centric because integration, policy, and logging can align more naturally with AKS and other Microsoft services. The limitation is breadth, not capability: once the environment spans multiple clouds, third-party services, or non-Azure workflows, the governance model becomes fragmented. That fragmentation matters because secret lifecycle control depends on visibility across creation, binding, use, and termination. A vault that is strong inside one ecosystem can still leave blind spots outside it.

Practical implication: map your actual cloud footprint before committing secret governance to an ecosystem-bound model.

Threat narrative

Attacker objective: The attacker seeks durable credential access that can be reused to reach applications, data, and adjacent cloud services.

1. Entry occurs when a secret is embedded in code, chat, or cluster configuration and becomes reachable outside its intended storage boundary.
2. Credential access follows when an exposed token, API key, or Vault credential grants legitimate access to secrets or downstream systems.
3. Impact occurs when overbroad access or unrecovered secrets enable lateral movement, data exposure, or service compromise across the Kubernetes estate.

Breaches seen in the wild

• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Secret storage is not secret governance: The article reflects a common enterprise mistake: treating the vault as the control, when the real control problem is lifecycle, visibility, and authorization scope. Encryption helps only if issuance, monitoring, and revocation are equally disciplined. The implication is that IAM teams must manage secrets as governed identities, not as passive records.

Vault token scope is the hidden blast radius: The article makes clear that the credential used to reach the vault can be more dangerous than the secrets inside it. If a single token can fetch many secrets, the practical boundary is not the vault instance but the token's privilege envelope. Practitioners should read this as a call to reduce standing reach, not just protect storage.

Namespace separation does not equal exposure separation: Multiple vaults, application-specific stores, or AKS-native injection can still fail if the same secret is reused across apps or environments. That pattern creates identity blast radius: one exposed credential can affect several workloads at once. Teams should treat secret reuse as a governance defect, not an operational convenience.

Cross-platform secret visibility is now the decisive control gap: Secrets leak into Slack, Jira, Confluence, and code because modern delivery chains are wider than any one vault. The issue is not whether a vault can hold the secret, but whether the organisation can see where the secret has already travelled. The practitioner conclusion is to govern secrets across collaboration, code, and runtime, not only in storage.

Identity lifecycle for machine access is still underdeveloped: The article shows why machine credentials need the same joiner-mover-leaver discipline that humans receive, but with more automation around issuance and revocation. A secret that outlives the workload, environment, or vendor relationship becomes an orphaned identity. The implication is to make offboarding and rotation first-class controls in NHI governance.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.
• For a broader view of how credentials escape into operational workflows, see Guide to the Secret Sprawl Challenge, which traces exposure paths and control gaps across the delivery chain.

What this signals

Secret sprawl is now a lifecycle problem, not a vault problem: When credentials travel into tickets, chat, and code, the governance boundary moves with them. Teams that rely on a single storage layer will miss the exposure paths that create the real risk. A useful next step is to align secret ownership, expiry, and revocation with workload lifecycle, not infrastructure convenience.

The practical shift is toward broader identity observability across the delivery stack. For teams already using Kubernetes, the question is no longer whether a vault exists, but whether they can prove where a secret lives, who can fetch it, and when it becomes invalid.

The most durable programmes will connect secret governance to workload identity and lifecycle controls, then verify those controls against external guidance such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.

For practitioners

• Map every secret to an owning workload and expiry rule Create a register that ties each API key, token, certificate, and SSH secret to a named workload, environment, and revocation trigger. If you cannot identify who owns revocation, the secret is already outside governance.
• Limit vault tokens to the smallest usable scope Issue separate tokens for separate applications, environments, and operational functions so one compromise cannot unlock the entire vault. Review whether any token can enumerate secrets it does not need to serve.
• Scan collaboration and code channels for secret drift Continuously search Slack, Jira, Confluence, repositories, and build logs for credentials that escaped the intended vault boundary. Correlate findings with access logs so exposure in one channel triggers revocation in the others.
• Use platform-specific vaults without fragmenting governance If you run both Azure and non-Azure estates, keep the control model consistent across them even when the implementation differs. Avoid assuming an ecosystem-native vault removes the need for central policy, revocation, and audit oversight.

Key takeaways

• Kubernetes secret security fails when teams treat vaulting as the end state rather than the start of lifecycle governance.
• Exposure moves through tokens, chat, code, and duplicated storage, so monitoring must cover the full delivery chain.
• Rotation, revocation, and least privilege only work when secret ownership and access scope are explicit and continuously enforced.

Key terms

• Kubernetes Secret: A Kubernetes Secret is a storage object for sensitive data such as tokens, passwords, certificates, and keys. It reduces the temptation to hardcode credentials, but by itself it does not provide full lifecycle governance, cross-system visibility, or strong assurance that the credential will be revoked when it should be.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, chat, tickets, build logs, repositories, and cloud services. It creates hidden copies of the same identity artifact, increasing exposure paths and making it much harder to know which secret is authoritative or safe to revoke.
• Workload Identity: Workload identity is the way a non-human workload proves who it is when it accesses data, services, or secrets. In practice it should be scoped to the workload's actual purpose, with short-lived credentials and clear ownership so the identity does not outlive the system it serves.
• Vault Token: A vault token is the credential used to authenticate to a secrets vault and request secrets or policy-bound actions. If it is broadly scoped, long-lived, or poorly monitored, it can become the real blast-radius driver because whoever holds it can often retrieve many secrets at once.

What's in the full article

Entro Security's full blog covers the operational detail this post intentionally leaves for the source:

• Step-by-step comparisons of Azure Key Vault and HashiCorp Vault setup paths for Kubernetes environments
• Implementation-specific notes on Vault Agent, CSI injection, and AKS integration choices
• Practical pros and cons of each vault model for access control, logging, and secret delivery
• Vendor guidance on the trade-offs between ecosystem-native integration and cross-platform flexibility

👉 Entro Security's full post covers the Vault and Key Vault setup details, security trade-offs, and Kubernetes integration paths.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.