Kubernetes Secrets still need real access controls and rotation

At a glance

What this is: Kubernetes Secrets are a built-in way to distribute credentials at runtime, but their default storage and access model leaves material exposure if teams rely on Kubernetes alone.

Why it matters: For IAM, NHI, and platform teams, the article shows that secret handling in Kubernetes is an identity governance problem as much as a deployment problem.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• 17 minutes

👉 Read Infisical's explanation of Kubernetes Secrets and production safeguards

Context

Kubernetes Secrets are objects for storing credentials, tokens, certificates, and API keys so applications can consume them at runtime instead of hardcoding sensitive data into images or manifests. The governance gap is that the default model depends on access control and cluster discipline, not on encryption or isolation by default, which makes secrets management an identity problem inside the orchestration layer.

That matters because Kubernetes permissions are coarse. If a service account, Pod creator, or namespace administrator can read a Secret, the underlying credential becomes a reusable non-human identity asset that can be copied, mounted, and moved laterally across workloads. That is why the topic belongs in NHI governance, not just platform engineering.

Key questions

Q: What breaks when Kubernetes Secrets are used without encryption at rest?

A: Without encryption at rest, the control plane stores Secret values in etcd in a form that can be recovered by anyone with sufficient API or backend access. That means the cluster’s administrative boundary, not the Secret object itself, becomes the security boundary. If an attacker reaches etcd or a privileged management plane, they can extract credentials and reuse them elsewhere.

Q: Why do Kubernetes Secrets create more risk when RBAC is too broad?

A: RBAC is object-scoped, so a workload that can read a Secret often gets every key in that object, not just the value it needs. If service accounts are over-permissioned, one Pod compromise can expose database passwords, registry credentials, and API keys together. That turns a small privilege mistake into a wide credential-loss event.

Q: What do security teams get wrong about Kubernetes Secrets?

A: Teams often confuse storing a credential in Kubernetes with securing it. Base64 encoding is only representation, namespace boundaries are not absolute isolation, and runtime mounting does not eliminate control-plane exposure. Real protection comes from encryption, least privilege, external secret governance, and lifecycle discipline across workloads.

Q: How should organisations reduce the blast radius of secret exposure in Kubernetes?

A: They should separate credentials by application and environment, constrain service account permissions to the minimum needed, and move production secrets into an external store with audit and rotation controls. The goal is to prevent one workload from becoming a reusable bridge to unrelated systems. That is how teams shrink the blast radius of a compromise.

Technical breakdown

Why Kubernetes Secret storage is not protection by itself

Kubernetes Secrets are base64-encoded for transport and stored in etcd by default unless encryption at rest is explicitly configured. Base64 is not encryption, so anyone with API access or etcd access can recover the original value. The runtime path is more nuanced because kubelet can mount secrets in memory-backed storage, but that does not change the central issue: the durable copy in the control plane remains accessible to anyone with sufficient cluster privilege. Practical implication: treat Secret storage as a control-plane exposure problem, not a formatting problem.

Practical implication: enable encryption at rest in etcd and review who can reach the control plane data path.

How RBAC and namespace scope create Secret exposure

Kubernetes RBAC protects Secret objects, not individual fields inside them. That means a Pod or service account granted read access to a Secret can usually obtain every key in that object, even if it only needs one value. Namespace scoping helps, but it is not a hard boundary when cluster roles, automation, backup tools, or privileged operators cross namespaces. The result is a broad identity blast radius: one over-permissioned workload can reveal credentials for multiple applications. Practical implication: map Secret access to the smallest possible service account and split high-value credentials into separate objects.

Practical implication: separate sensitive credentials by workload and namespace, then audit for cluster-wide read paths.

Why external secret management changes the operating model

External secret management moves the system of record out of Kubernetes and into a dedicated control plane with rotation, audit, and lifecycle features. In practice, this reduces dependence on static cluster persistence and gives teams a better place to manage credential issuance, renewal, and revocation. It also improves integration with identity systems because access to the secret store can be governed independently from access to the cluster. The trade-off is operational complexity: teams must coordinate application refresh, restart, and synchronization timing. Practical implication: use external secret providers for production workloads that need auditability and rotation discipline.

Practical implication: reserve native Secrets for low-risk use cases and move production credentials to an external secret store.

Threat narrative

Attacker objective: The objective is to turn Kubernetes control-plane access into reusable credential access across workloads and downstream services.

1. Entry occurs when an attacker or overly broad workload gains access to the Kubernetes API, a privileged namespace, or the etcd backend that stores Secret objects.
2. Credential access follows when the actor reads Secret objects, decodes base64 values, or mounts credentials through a Pod that has permission to consume them.
3. Impact occurs when those credentials are reused for database access, registry authentication, or other downstream systems, turning one cluster issue into wider environment compromise.

Breaches seen in the wild

• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.
• Google Firebase misconfiguration breach — Firebase misconfigurations exposed 19.8M secrets across developer instances.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Kubernetes Secrets are a governance layer, not a security boundary. The article makes the default model plain: Kubernetes stores secrets for convenience, then relies on RBAC and operational hygiene to prevent misuse. That means the security outcome is only as strong as the surrounding identity controls. In NHI terms, the credential is protected by policy, not by the secret object itself. Practitioners should treat every Secret as an access-governed asset with a lifecycle, not as an intrinsically safe container.

Secret exposure becomes identity blast radius when one Pod can read too much. The key failure mode is not just that a secret exists, but that Kubernetes permissions are often wider than the workload actually needs. When a single service account can read many values in one object, a compromise turns into broad credential reuse. That pattern aligns directly with OWASP-NHI concerns around overprivilege and secret sprawl. The practitioner takeaway is to design for the smallest recoverable blast radius, because object-level access is the real control surface.

External secret stores are increasingly the operational baseline for production NHI governance. Native Secrets still have a place, but the article shows why production teams usually need encryption at rest, audit trails, rotation workflows, and decoupled secret lifecycle handling. That shifts the centre of gravity from Kubernetes as the source of truth to a dedicated secret governance plane. For teams responsible for machine identity, the implication is clear: production credential governance now requires controls that survive cluster compromise, not just controls inside the cluster.

Secret rotation is a lifecycle problem, not a YAML problem. The article correctly links rotation to distribution, restart behaviour, and application readiness. That makes secret management part of identity lifecycle governance rather than a one-time configuration task. The hard part is not generating a new value, but moving every dependent workload to it without leaving stale access behind. Practitioners should evaluate rotation as an entitlement transition, with clear ownership and revocation checkpoints.

Named concept: identity blast radius. Kubernetes makes it easy for a single credential or service account to reach more workloads than intended when object-level permissions are broad. That creates a compact but dangerous blast radius, where one namespace or one Pod can expose multiple downstream identities. The implication is that secret governance must be measured by how far one compromise can travel, not by whether a secret is technically stored outside application code.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• That is why the governance conversation now extends beyond storage to lifecycle control, as explored in Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

What this signals

Identity blast radius is the right lens for Kubernetes secret governance. The practical question is not whether secrets are stored separately from code, but how far one compromised Pod, namespace, or service account can travel once it has read access. Teams that still treat secret handling as a deployment detail will miss the governance reality: object-level permissions define the real containment boundary.

With 44% of developers reported to follow security best practices for secrets management according to The State of Secrets in AppSec, secret hygiene remains uneven enough that platform defaults cannot be trusted as a control strategy. That makes least privilege, rotation, and audit ownership programme issues, not just developer preferences.

For Kubernetes-heavy environments, the next maturity step is to connect cluster permissions to the wider identity programme. Aligning workload access with the NIST Cybersecurity Framework 2.0 helps teams turn secret access into a governable control, rather than a hidden operational habit.

For practitioners

• Encrypt Secrets at rest in etcd Turn on secret encryption during cluster setup and store encryption keys in an external key management service or HSM, not on the same systems as the encrypted data.
• Split credentials by workload and environment Use separate Secret objects and service accounts for each application and environment so one compromised Pod cannot read unrelated credentials across namespaces.
• Move production credentials to an external secret store Use an external secret provider for production workloads that need audit logs, rotation discipline, and stronger lifecycle control than native cluster storage provides.
• Audit Pod-to-Secret access paths Review which Pods can create, mount, or read Secrets in each namespace, then remove broad read permissions and cross-namespace exceptions that are not operationally required.

Key takeaways

• Kubernetes Secrets reduce credential sprawl in code, but they do not secure credentials by default.
• RBAC scope, namespace design, and etcd storage determine whether one compromised workload becomes a cluster-wide exposure.
• Production teams need encryption, least privilege, audit trails, and external secret governance to keep secret risk within bounds.

Key terms

• Kubernetes Secret: A Kubernetes Secret is an object for storing sensitive values such as passwords, tokens, certificates, or registry credentials so workloads can consume them at runtime. It improves application hygiene, but its security depends on encryption, access control, and operational discipline rather than on the object format itself.
• Etcd: Etcd is the distributed key-value store used by Kubernetes as part of its control plane. When Secrets are persisted there without encryption at rest, anyone with sufficiently broad control-plane or backend access may recover the underlying values, which makes etcd a critical governance boundary.
• Secret rotation: Secret rotation is the controlled replacement of credentials after issuance, exposure, or expiry. In Kubernetes environments, rotation is not just a value change. It also includes updating dependent workloads, handling rollout timing, and revoking old access cleanly so stale credentials do not persist.
• Namespace scope: Namespace scope is the boundary Kubernetes uses to partition resources and permissions within a cluster. It helps reduce exposure, but it is not a complete isolation model because cluster-wide roles, shared infrastructure, and privileged automation can still cross that boundary and expose Secrets broadly.

What's in the full article

Infisical's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step examples of how Kubernetes Secrets are injected as environment variables, mounted as files, or used for image pulls.
• A practical comparison of native Secrets, external secret providers, and the External Secrets Operator for production use.
• More detail on encryption at rest configuration, including key handling and where the encryption material should live.
• Implementation trade-offs for secret rotation, audit logging, and multi-environment separation that platform teams need before rollout.

👉 Infisical's full post covers runtime patterns, storage behaviour, and production secret management trade-offs.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.