Notifications
Clear all
Topic starter
17/08/2026 4:41 pm
TL;DR: Native Kubernetes secrets handling falls short on encryption, access control, auditing, and compliance in multi-cloud and hybrid deployments, especially when clusters span regions and teams, according to Akeyless. The practical issue is not storage alone but governed, auditable delivery of secrets across environments.
NHIMG editorial — based on content published by Akeyless: Kubernetes secrets management gaps in hybrid and multi-cloud deployments
Questions worth separating out
Q: How should security teams govern secrets in Kubernetes and Terraform environments?
A: Treat secret encryption as one control within a wider NHI programme.
Q: Why do native Kubernetes secrets controls fail in large environments?
A: They fail because encoding is not encryption, RBAC is often too broad, and monitoring is fragmented across clusters and cloud providers.
Q: What breaks when secrets are injected into workloads without identity governance?
A: The workload may receive a valid secret, but the organisation loses assurance about who requested it, who could reuse it, and whether it was revoked on schedule.
Practitioner guidance
- Separate secret storage from secret governance Inventory where Kubernetes secrets are stored, where they are injected, and which system actually owns rotation, revocation, and audit.
- Replace broad secret-read roles with workload-scoped policies Review every role that can read secrets and narrow it to specific workloads, namespaces, and operations.
- Prefer runtime injection over persistent secret objects Move applications to runtime delivery through sidecars, file injection, CSI, or external secrets operators where the secret does not need to persist inside the cluster.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step Kubernetes plugin examples for injecting secrets through environment variables, files, sidecars, and CSI.
- Configuration examples for external secrets operator, key management service, and cert-manager integrations.
- Implementation detail on dynamic credentials, automatic revocation, and rotation workflows across cloud providers.
- Practical deployment patterns for using Akeyless across AWS, Azure, GCP, and on-premises clusters.
👉 Read Akeyless' analysis of Kubernetes secrets management gaps and runtime injection →
Kubernetes secrets management: are your controls keeping up?
Explore further
View Full Forum → | NHI Foundation Course → | Our Services →
17/08/2026 4:46 pm
Native Kubernetes secrets handling creates a governance illusion: the platform can store secrets, but it does not automatically solve lifecycle control, access granularity, or audit completeness. That is why base64-encoded values, namespace-scoped RBAC, and fragmented provider logging become operational risk at scale. The implication is that secret governance must be treated as an identity function, not a cluster feature.
A few things that frame the scale:
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
- A separate finding shows that 35.6% of organisations cite consistent access across hybrid and multi-cloud environments as their top NHI security challenge.
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 management gaps persist in hybrid cloud deployments
