TL;DR: Akeyless shows that Kubernetes Secrets still create compliance and rotation gaps because default base64 storage, manual encryption setup, limited auditing, and no automatic rotation leave sensitive data harder to govern. The underlying issue is assuming cluster-native secret handling can satisfy modern NHI control and compliance requirements.
At a glance
What this is: This article argues that Kubernetes Secrets leave organisations exposed through weak default storage, limited auditing, and manual rotation controls.
Why it matters: IAM and platform teams need to treat Kubernetes Secrets as a governance problem, not just a storage choice, because weak lifecycle controls expand exposure across workloads and compliance processes.
👉 Read Akeyless's analysis of Kubernetes Secrets compliance and rotation gaps
Context
Kubernetes Secrets are the native mechanism many clusters use to store passwords, tokens, and keys, but their default behaviour does not provide the level of lifecycle control identity teams need. The problem is not Kubernetes as an orchestration platform, but the assumption that its built-in secret handling is enough for modern NHI governance.
The article’s central point is that storage, access, auditability, and rotation are being treated as separate implementation tasks when they are actually one governance problem. Once secrets are scattered across clusters without consistent encryption, logging, and offboarding discipline, the security model becomes operationally fragile.
That makes Kubernetes Secrets a practical identity risk as much as a platform configuration issue. For IAM and security teams, the question is whether cluster-native secret handling can meet enterprise expectations for accountability, rotation, and blast-radius reduction.
Key questions
Q: What breaks when Kubernetes secrets are treated as fully protected after EKS encryption is enabled?
A: The assumption that storage security equals access security breaks immediately. EKS encryption protects secrets in etcd, but it does not remove the need to control who can create, read, mount, or update those secrets. Without that governance layer, the decryption path becomes the real attack surface.
A: Organisations should prioritise centralized secrets management when multiple clusters, teams, or applications are involved, because local handling quickly creates duplication and inconsistent controls. A central approach improves rotation, auditability, and lifecycle governance across workloads. It is especially important when secrets are reused across environments or when manual updates create operational delays.
Q: What are the signs that Kubernetes access controls are not working as intended?
A: Warning signs include overprivileged service accounts, inconsistent permissions across environments, plaintext credentials in manifests, and unclear audit trails for who accessed what and why. If teams must rely on manual fixes during deployments or incidents, access control is probably too loose or too fragmented. Healthy controls should support repeatable policy enforcement, traceable access, and rapid revocation when conditions change.
Q: What should teams do when a Kubernetes secret may be exposed or outdated?
A: Teams should replace the secret, revoke the old credential, and verify which workloads depended on it before redeploying. The priority is to close the exposure window and prevent stale credentials from remaining valid after the original purpose has ended. If rotation is difficult, that difficulty itself is evidence that the lifecycle model is too weak.
Technical breakdown
Why base64 storage is not encryption for Kubernetes Secrets
Kubernetes Secrets are stored in etcd and, by default, the data is encoded rather than encrypted. Base64 is reversible encoding, so anyone with access to the datastore can recover the secret unless encryption at rest is explicitly enabled and configured correctly. That configuration adds key-management overhead and creates another place where misconfiguration can expose sensitive data. Even when encryption is enabled, the secret is still available to workloads after retrieval, so the protection boundary ends at storage, not at use.
Practical implication: treat default Kubernetes Secret storage as readable data exposure unless encryption at rest is verified and governed.
How RBAC and auditing gaps turn secret access into blind spots
Kubernetes access control can restrict who reads Secrets, but the article highlights that RBAC mistakes still create unintended access paths. The larger issue is observability: native audit coverage is limited, so teams often cannot reliably trace who accessed a secret, when they did it, or whether access matched policy. That makes incident investigation and compliance evidence difficult. In identity terms, the secret exists without strong enough accountability around access and use.
Practical implication: pair Secret access controls with audit logging that can prove access, not just deny it.
Why manual rotation makes Kubernetes Secrets a lifecycle problem
Secret rotation is where Kubernetes Secrets become a governance problem rather than a storage convenience. The article notes there is no automatic rotation, so teams must coordinate updates across applications, clusters, and deployment pipelines without breaking workloads. That creates long exposure windows for compromised credentials and raises the risk of stale credentials persisting beyond their intended use. For NHI governance, a secret that cannot be rotated cleanly is a secret that retains standing risk.
Practical implication: define rotation as a lifecycle requirement for every Kubernetes secret, not as an optional operational task.
Breaches seen in the wild
- SAP Kubernetes secrets exposure 2023: Kubernetes secrets committed to GitHub exposed 203 valid registry credentials, including SAP artifact repository access. SAP closed it after Aqua's report.
- 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 expose an identity governance gap, not just a storage gap: The article shows that default encoding, limited auditing, and manual rotation leave sensitive credentials outside the control model IAM teams expect. Kubernetes can store the secret, but it does not by itself provide the governance fabric needed to prove who can access it, when it changed, or whether it still belongs in circulation. Practitioners should treat the secret lifecycle as a governed identity asset, not a cluster convenience.
Long-lived secrets are the real compliance problem: The article’s strongest signal is not encryption alone but the persistence of credentials that remain valid longer than their risk posture justifies. When rotation is manual, the organisation inherits a larger attack window and a weaker compliance story at the same time. That is why lifecycle control, not just storage hardening, becomes the decisive variable for NHI risk management.
Secret sprawl in Kubernetes creates control fragmentation: Each cluster that manages its own secrets independently turns one governance policy into many local exceptions. That fragmentation weakens consistent offboarding, recertification, and evidence collection across environments. The practitioner conclusion is straightforward: if the secret estate cannot be governed centrally, it will be governed inconsistently.
Kubernetes-native handling does not satisfy modern NHI expectations by default: The article assumes that built-in cluster features should be enough for sensitive credentials, but that assumption breaks under enterprise audit, rotation, and access review demands. The issue is not whether Kubernetes can store secrets, but whether it can sustain the controls required for accountable machine identity governance. Teams should reassess where platform convenience ends and governance responsibility begins.
What this signals
Secret governance has become a lifecycle issue: Kubernetes teams often treat storage and rotation as separate tasks, but the article shows they fail together when secrets are not governed as living credentials. Once a credential is created inside a cluster, it needs ownership, expiry, access review, and revocation logic that survives deployment churn.
That shifts the programme question from whether Kubernetes can store a secret to whether the organisation can still prove control over it after distribution. For IAM and platform teams, the practical test is whether secret handling remains intelligible at audit time, not just at deployment time.
For practitioners
- Validate encryption at rest for all cluster secrets Confirm that etcd encryption is enabled, correctly configured, and monitored for drift across every cluster before treating Kubernetes Secrets as protected.
- Tighten RBAC around secret read paths Review which service accounts, operators, and workloads can read Secrets and remove broad permissions that make accidental or unauthorised access possible.
- Make secret rotation a default lifecycle control Set rotation expectations for passwords, tokens, and keys used in clusters, and map each secret to an owner, expiry trigger, and replacement path.
- Centralise audit evidence for secret access Capture access, modification, and administrative events in a way that supports incident review and compliance reporting across all clusters.
Key takeaways
- Kubernetes Secrets expose a governance gap because default storage, access, and rotation controls do not provide the accountability modern identity programmes need.
- The article’s core risk is persistent credential exposure across clusters, especially when encryption, auditing, and rotation are handled manually or inconsistently.
- Teams should treat every Kubernetes secret as a governed lifecycle asset and move to controls that make access, rotation, and offboarding provable.
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 addresses the attack and risk surface, while CIS Controls v8 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 default storage protections. |
| NHI-07 — Long-Lived Secrets | The article stresses that Kubernetes Secrets lack automatic rotation and can remain valid too long. | |
| NHI-05 — Overprivileged NHI | Misconfigured RBAC can let service accounts and workloads read more secrets than they need. | |
| Recommendation — Scan cluster secret stores for leakage paths and eliminate plain-text exposure in etcd and logs. Set expiry and rotation expectations for every cluster secret and remove credentials that outlive their task. Reduce secret read permissions to the minimum set of workloads and service accounts that require them. | ||
| CIS Controls v8 | CIS-5 — Account Management | Secret access and ownership are part of account governance across Kubernetes clusters. |
| Recommendation — Tie secret ownership and revocation to account lifecycle reviews so stale access does not persist. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article focuses on controlling who can access Kubernetes Secrets and proving those permissions. |
| Recommendation — Review and restrict Kubernetes secret entitlements so access is aligned with approved business need. | ||
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 Rotation: Secrets rotation is the practice of replacing credentials on a schedule or after an event so exposed values stop working quickly. In NHI programmes, rotation must be tied to ownership and automation, otherwise credentials remain valid long after teams believe the risk has been addressed.
- Encrypted At Rest: A storage control that protects secrets while they sit on disk or in a file. It reduces casual disclosure, but it does not guarantee that only the original actor can request decryption, so it must be paired with runtime scoping and identity-aware access rules.
- 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.
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 Kubernetes stores secrets in etcd and where the default exposure boundaries sit
- Configuration detail for enabling encryption at rest and managing the associated key handling burden
- Examples of Kubernetes integrations that inject secrets into pods and reduce hard-coded credential use
- Compliance discussion covering GDPR, HIPAA, and PCI-DSS expectations for secrets handling
Deepen your knowledge
NHI governance, secrets management, and workload identity security 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