Topic starter
17/08/2026 4:41 pm
TL;DR: Akeyless says Kubernetes secrets management still falls short on encryption, access control, auditing and compliance across hybrid and multi-cloud deployments. The practical issue is governed, auditable delivery of secrets across clusters and regions, not storage alone.
Editorial analysis by NHI Mgmt Group, based on content published by Akeyless: “Bulletproof Kubernetes Secrets Management: Common Challenges and Solutions”.
Key questions
Q: What breaks when Kubernetes secrets are handled manually?
A: Manual handling usually creates duplication, stale credentials, and unclear ownership.
Q: Why do Kubernetes secrets create compliance risk in multi-cloud environments?
A: Because the control problem follows the data wherever the cluster runs.
Q: How do security teams reduce over-permissioning for Kubernetes secrets?
A: Start by mapping which workloads truly need read access to which secrets, then remove namespace-wide access by default.
Practitioner guidance
- Implement real encryption at rest for Kubernetes secrets Configure an encryption provider for secrets and verify that the setting is consistent across every cluster, namespace and region.
- Tighten RBAC around secret retrieval Replace namespace-wide secret access with the smallest practical set of read permissions for each workload and service account.
- Centralise audit trails for secret access Correlate Kubernetes events with cloud audit logs so you can answer who accessed a secret, from where, and for what purpose.
Bottom line: Kubernetes-native secret handling often leaves encryption, access control and audit visibility too weak for hybrid cloud deployments.
What's in the full article
Akeyless' full article covers the operational detail this post intentionally leaves for the source:
- Example Kubernetes YAML for encryption at rest with an AES-CBC provider
- Step-by-step patterns for the Akeyless K8s Secrets Injector, External Secrets Operator and CSI integration
- Runtime delivery examples for static, dynamic and rotated secrets in pods
- Certificate issuance, renewal and revocation workflows through Kubernetes integrations
👉 Read Akeyless' analysis of Kubernetes secrets management gaps in hybrid cloud deployments →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
17/08/2026 4:46 pm
Kubernetes secrets management is really identity governance in cluster form: the core issue is not where a secret is stored, but which identity can retrieve it, when, and under what policy. In hybrid environments, a secret that is technically present in multiple places is operationally governed only if access, audit and revocation are centrally controlled. Practitioners should treat Kubernetes secrets as part of the identity lifecycle, not as a YAML convenience.
A few things that frame the scale:
- 54% of organisations are dissatisfied with their current secrets management solution because not all secrets are secured, and 43% cite lack of central management, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: Should organisations store Kubernetes secrets in the cluster or inject them at runtime?
A: For most high-value credentials, runtime injection is safer because it avoids leaving secrets persistently stored in the cluster. The decision still depends on audit, rotation and revocation processes outside Kubernetes. If those controls are weak, runtime delivery reduces exposure but does not solve governance by itself.
👉 Read our full editorial: Kubernetes secrets management gaps persist in hybrid cloud deployments