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.
At a glance
What this is: This article argues that native Kubernetes secrets handling is not enough for hybrid and multi-cloud deployments because weak encryption, broad access and limited auditing leave sensitive data exposed.
Why it matters: IAM, PAM and NHI teams need to treat Kubernetes secrets as a governed identity problem, because over-broad access and poor visibility create compliance and blast-radius risk across clusters.
👉 Read Akeyless' analysis of Kubernetes secrets management gaps in hybrid cloud deployments
Context
Kubernetes secrets management is the discipline of protecting API keys, passwords, credentials and certificates as they move through clusters, pipelines and runtime workloads. In hybrid and multi-cloud environments, the governance gap is that native cluster controls often stop at storage and namespace boundaries, while the real risk lives in how secrets are issued, accessed, audited and revoked across regions.
Akeyless frames the problem as one of operational control rather than simple secret storage. That matters because organisations running multiple clusters need consistent policy enforcement, visible access trails and region-aware handling of sensitive data, otherwise the same secret can be exposed in more than one control plane at once.
Key questions
Q: What breaks when Kubernetes secrets are handled manually?
A: Manual handling usually creates duplication, stale credentials, and unclear ownership. Once secrets are copied into files, CI jobs, or shared configurations, no one can reliably prove where they exist or who can still use them. That turns rotation into a reactive cleanup exercise instead of a controlled lifecycle process.
Q: Why do Kubernetes secrets create compliance risk in multi-cloud environments?
A: Because the control problem follows the data wherever the cluster runs. If secrets can be accessed in multiple regions, but audit evidence and residency controls are fragmented, teams cannot prove that access matched policy or local requirements. Compliance then depends on coordination across tools rather than one enforceable governance model.
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. The goal is to make every secret retrieval decision specific to the workload and identity involved. That reduces role sprawl, lowers blast radius and makes access reviews meaningful.
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.
Technical breakdown
Why base64-encoded Kubernetes secrets are not encryption
Kubernetes stores secrets in a format that is easy to retrieve if an attacker reaches the API server, etcd, or any control path that exposes the data. Base64 encoding is reversible and does not provide confidentiality. Encryption at rest can reduce exposure, but only if cluster operators configure an encryption provider correctly and maintain it consistently across environments. In hybrid deployments, that requirement becomes harder because the same control must be applied repeatedly across clusters, regions and teams, with no drift. Practical implication: treat default Kubernetes secret storage as a convenience layer, not a protection boundary, and govern encryption separately from application deployment.
Practical implication: do not rely on native secret encoding as a security control; enforce real encryption and verify it across every cluster.
How RBAC and role explosion weaken secret access control
Kubernetes RBAC can grant broad access to all secrets in a namespace, which is often too coarse for real-world workloads. As teams multiply roles, bindings and namespaces, policy sprawl makes it harder to know who can read which secret and why. This is a governance problem as much as a technical one, because decentralised access decisions produce inconsistent permissions and missed reviews. The result is over-permissioning, especially when operators simplify roles to keep pace with environment growth. Practical implication: move from namespace-wide access assumptions to secret-level governance, with central visibility over which identities can retrieve each credential.
Practical implication: reduce broad namespace access and review role bindings as an access governance issue, not only a Kubernetes configuration task.
Why auditing secret access is essential in hybrid cloud
Native Kubernetes does not provide detailed secret-specific audit trails, so teams often have to stitch together logs from cloud services and cluster tooling. That creates blind spots when secrets move between AWS, Azure, GCP and on-premises environments. Without a consistent audit layer, organisations cannot reliably answer who accessed a secret, when it was used, or whether access matched policy. That is a direct compliance and incident-response problem, not just a reporting inconvenience. Practical implication: implement central audit coverage for secret access and make event correlation part of the secrets management design, especially where sovereignty requirements apply.
Practical implication: centralise audit visibility before you expand clusters across clouds or regions, otherwise access evidence will remain fragmented.
Threat narrative
Attacker objective: The objective is to recover and reuse sensitive credentials so applications, services or administrative paths can be accessed without authorised oversight.
- Entry occurs when an attacker or unintended system gains access to the Kubernetes API, etcd, or another path that reveals stored secrets. Because native secret encoding is reversible, the exposed material can be recovered quickly once that control boundary is crossed.
- Escalation follows when broad RBAC permissions or namespace-wide access allow the same secret to be reused across applications or services. In a hybrid environment, that access can cross clusters and teams, expanding the blast radius.
- Impact is the exposure of API keys, passwords, credentials or certificates that can be used to impersonate workloads, access services, or violate regional compliance requirements. The article’s central risk is not just disclosure, but uncontrolled reuse across multiple environments.
Breaches seen in the wild
- iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.
- Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
Namespace-wide access is a governance shortcut that becomes a blast-radius problem: RBAC in Kubernetes often grants more access than workload intent requires, and that gap widens as teams add roles to keep up with platform growth. The result is role explosion, inconsistent bindings and weak reviewability. The practitioner takeaway is that over-broad retrieval rights are a control failure, not an acceptable default.
Hybrid and multi-cloud secrets handling exposes a compliance boundary that native controls do not close: data residency, sovereignty and audit requirements depend on knowing where a secret lives and who touched it across regions. Kubernetes alone does not create that evidence chain. For security leaders, the question is whether secrets governance is measurable across the full deployment footprint or only within isolated clusters.
Ephemeral delivery changes the security model for Kubernetes secrets: runtime injection and just-in-time credentials reduce persistent exposure, but only when issuance, revocation and audit are coordinated outside the cluster. That shifts secrets management from storage-centric thinking to lifecycle-centric governance. Practitioners should reframe the control objective as minimising standing secret presence and maximising traceable access.
Centralised secrets control is becoming the baseline for container governance: organisations operating at scale cannot reliably manage access, encryption and compliance through isolated cluster policies. The market signal is that secrets management is converging with broader identity governance, especially where workloads span clouds and regions. Practitioners should align container security, IGA and NHI ownership around one policy model.
From our research library:
- 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.
- Read next: Secrets Management Buyer's Guide
What this signals
Centralised secret governance is becoming the operating model: once teams run the same workloads across AWS, Azure, GCP and on-premises, isolated cluster policy no longer scales. The practical shift is toward one access and audit model for secrets, with cluster-native controls treated as local enforcement rather than the source of truth.
Hybrid deployment multiplies the hidden secret sprawl problem: organisations are already concerned about secrets sprawl, and the concern rises when teams have to manage different clusters, different RBAC patterns and different audit paths across environments, according to the 2024 State of Secrets Management Survey. That makes governance maturity, not just technical hardening, the differentiator.
Runtime delivery is the control boundary that matters most: if a secret lives long enough to be copied into manifests, logged by tooling or reused across environments, the exposure window has already widened. The better design is to issue secrets as close as possible to use and revoke them as soon as the workload no longer needs them.
For practitioners
- 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. Base64 encoding is not a security boundary, so the control must be enforced outside the default storage path.
- Tighten RBAC around secret retrieval Replace namespace-wide secret access with the smallest practical set of read permissions for each workload and service account. Review RoleBindings and ClusterRoleBindings as a recurring access governance task, not just a deployment task.
- 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. Use the same reporting layer across AWS, Azure, GCP and on-premises clusters.
- Move high-value secrets to runtime injection Deliver secrets at runtime rather than storing them persistently inside clusters, especially for pods that only need temporary access. This reduces the amount of recoverable secret material sitting in the control plane or manifests.
Key takeaways
- Kubernetes-native secret handling often leaves encryption, access control and audit visibility too weak for hybrid cloud deployments.
- The most damaging failure mode is not storage alone but the combination of broad retrieval rights and inconsistent governance across clusters.
- Runtime delivery, tighter role boundaries and central audit coverage are the controls that materially change the risk profile.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed Kubernetes secrets and weak protection of credentials in clusters. |
| NHI-05 — Overprivileged NHI | Broad RBAC access to secrets creates over-privileged workloads and service accounts. | |
| NHI-07 — Long-Lived Secrets | The article argues for runtime delivery and rotation to reduce standing secret exposure. | |
| Recommendation — Scan cluster storage, manifests and pipelines for exposed secrets and revoke anything recoverable. Reduce secret retrieval rights to the smallest workload-specific scope and review bindings routinely. Shorten secret lifetime by injecting credentials at use time and rotating them on schedule. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Secret rotation and lifecycle management map directly to credential management controls. |
| Recommendation — Apply authenticator lifecycle controls to rotate, revoke and replace Kubernetes secrets on time. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article’s threat path is secrets exposure followed by reuse across services and clusters. |
| Recommendation — Map exposed secrets to credential access and lateral movement to prioritise containment. | ||
| NIST Zero Trust (SP 800-207) | Least privilege access — Least privilege access | The article relies on zero trust assumptions to reduce implicit access to secrets across environments. |
| Recommendation — Enforce least-privilege access so secret retrieval is explicitly authorised per workload and context. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Secrets governance depends on clear entitlements and authorisations for every workload and user. |
| Recommendation — Review and trim secret entitlements so each identity can only access approved credentials. | ||
Key terms
- Kubernetes Secret: A Kubernetes Secret is an object used to store sensitive data such as passwords, tokens, certificates, and API keys outside application code. It simplifies delivery to Pods, but it does not automatically protect the data. Security depends on storage encryption, access control, and monitoring of how the secret is used.
- Secrets Sprawl: The uncontrolled proliferation of sensitive credentials, API keys, tokens, passwords, certificates, across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
- Runtime Secret Injection: A pattern that retrieves credentials only when a process starts, rather than storing them in files or source control. For AI developer tools, it reduces secret persistence, limits accidental disclosure, and keeps the credential tied to a specific execution session.
- Role Explosion: Role explosion happens when a shared authorization model accumulates too many narrowly tailored roles, often because every customer or team request becomes a permanent global role. The result is a harder-to-understand access catalogue, broader blast radius, and weaker governance over who can do what.
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
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 17, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org