Notifications
Clear all
Topic starter
25/06/2026 5:06 pm
TL;DR: Kubernetes secrets security still depends on how credentials are created, stored, rotated, and monitored, even when teams choose HashiCorp Vault or Azure Key Vault instead of native cluster secrets, according to Entro Security. The real issue is not vault selection alone but lifecycle visibility, least privilege, and exposure control across apps, chat, and code.
NHIMG editorial — based on content published by Entro Security: Managing Kubernetes secrets with HashiCorp Vault vs. Azure Key Vault
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- 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.
- 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.
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
👉 Read Entro Security's comparison of HashiCorp Vault and Azure Key Vault for Kubernetes secrets →
Kubernetes secrets governance: what IAM teams need to watch?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
25/06/2026 5:36 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Kubernetes secrets need lifecycle controls beyond Vault choice
