Notifications
Clear all
Topic starter
17/08/2026 4:40 pm
TL;DR: Kubernetes Secrets still leave organisations exposed through default base64 storage, manual encryption setup, limited auditing, and no automatic rotation, according to Akeyless. The real issue is not Kubernetes itself but the assumption that cluster-native secret handling can satisfy modern NHI governance, compliance, and blast-radius requirements.
NHIMG editorial — based on content published by Akeyless: why Kubernetes Secrets can be a liability for sensitive data management
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
Questions worth separating out
Q: How should teams manage Kubernetes Secrets in production clusters?
A: Treat Kubernetes Secrets as a convenience layer, not the governance authority.
Q: Why do Kubernetes secrets bridges create operational risk for NHI programmes?
A: They create risk because machine credentials are only useful if delivery, rotation, and refresh continue to work at cluster speed.
Q: What breaks when Kubernetes secrets are handled manually?
A: Manual handling usually creates duplication, stale credentials, and unclear ownership.
Practitioner guidance
- Inventory every Kubernetes-managed credential path Map which secrets are stored in etcd, injected into pods, passed through CI/CD, or duplicated across clusters.
- Disable implicit trust in default secret handling Require explicit encryption at rest, strict RBAC scoping, and audit logging before any secret is treated as production-ready.
- Move high-value credentials to centrally governed lifecycle controls Reserve Kubernetes-native storage for low-risk values where possible, and use centrally managed secret lifecycle tooling for credentials that can affect data access, deployment pipelines, or service-to-service trust.
What's in the full article
Akeyless's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step explanation of how its Kubernetes integrations inject secrets into pods and containers.
- Detailed description of the encryption and access-control mechanisms it claims to apply across environments.
- Specific compliance claims and audit-trail capabilities described for production deployment planning.
- The platform integration points with external secrets tooling and the Kubernetes secrets injector.
👉 Read Akeyless's analysis of why Kubernetes Secrets create compliance and rotation gaps →
Kubernetes Secrets and the governance gap teams keep missing?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Cluster-native secret storage is not a governance model. Kubernetes Secrets solve a packaging problem, not a lifecycle problem. If an organisation treats base64-encoded cluster data as a sufficient control, it is relying on a mechanism that was never designed to enforce durable ownership, rotation, or revocation across distributed workloads.
A few things that frame the scale:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%), according to The State of Non-Human Identity Security.
- Another finding from the same research shows that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared with nearly 1 in 4 for securing human identities.
A question worth separating out:
Q: Who is accountable when a Kubernetes secret is exposed?
A: Accountability usually sits with the platform, security, and application owners together, because secret exposure is a shared control failure. The key question is which team owns rotation, which team owns audit evidence, and which team can revoke access before the secret is reused elsewhere.
👉 Read our full editorial: Kubernetes Secrets create compliance and rotation gaps for IAM teams
