Kubernetes secrets and NHI governance: what teams miss

At a glance

What this is: This guide explains how Kubernetes Secrets are created, encoded, mounted, and monitored, and argues that the core control problem is non-human identity governance rather than simple storage.

Why it matters: IAM, PAM, and platform teams need to treat Kubernetes Secrets as governable machine credentials because weak handling turns cluster workloads, registry access, and service accounts into persistent exposure paths.

Context

Kubernetes Secrets are small objects for storing sensitive values used by workloads, including passwords, API keys, tokens, certificates, and registry credentials. The governance gap is that teams often focus on where the value sits, while the real control question is who or what can use it, for how long, and under what monitoring.

In container environments, secret handling is part of non-human identity governance because those values authenticate workloads to protected resources. Once secrets are hardcoded, broadly mounted, or left unmonitored, the cluster stops treating them as managed credentials and starts treating them as ambient access.

This article is therefore less about secret encoding than about lifecycle discipline for machine identities inside Kubernetes. The article’s baseline posture is common, but the operational risk it exposes is familiar across many enterprises: access is easier to issue than to govern.

Key questions

Q: What breaks when Kubernetes Secrets are only base64 encoded but not encrypted or monitored?

A: The control breaks at the point where representation is mistaken for protection. Base64 only hides the value from casual inspection, while the credential can still be exposed in code, manifests, environment variables, mounted volumes, or API logs. Without encryption, access review, and runtime monitoring, the secret remains usable even when the team assumes it is safe.

Q: Why do service accounts and tokens complicate Kubernetes access governance?

A: Service accounts and tokens complicate governance because they turn access into a secret-management problem as much as an identity problem. If the token is copied, the cluster cannot tell intent from reuse. That means teams need strict scope control, short lifetimes where possible, and a reliable offboarding process for every workload identity.

Q: How do security teams know whether secret monitoring is actually working in Kubernetes?

A: Monitoring is working when secret creation, update, and access events are visible, retained, and tied to an alerting process that can distinguish expected workload use from unusual access. If teams can only inventory secrets but cannot explain who read them or when they were last rotated, the monitoring layer is incomplete.

Q: What is the difference between Kubernetes secret rotation and secret encryption at rest?

A: Rotation changes the credential itself so older copies stop being valid, while encryption at rest protects stored secret material from direct disclosure in persistent storage. They solve different problems. Rotation limits the time a credential can be abused, and encryption limits the damage if storage is exposed. Mature governance needs both controls.

Technical breakdown

Kubernetes Secrets as workload credentials

Kubernetes Secrets are not encryption by themselves. They are a Kubernetes object type for storing sensitive data that workloads need at runtime, and the platform then exposes that data through volumes, environment variables, image pull references, or service account token flows. That makes them a delivery mechanism for non-human identity credentials, not merely a storage format. Base64 encoding is only representation, while encryption at rest depends on cluster configuration and the underlying storage path. The technical risk is that secret material can be distributed correctly while still being overexposed, long-lived, or accessible to more pods and processes than intended.

Practical implication: Treat secret delivery as identity scope design, not just data formatting.

Why base64 and encrypted storage are different controls

Base64 in a YAML manifest is reversible and exists for transport convenience, not secrecy. Kubernetes can also encrypt secrets at rest in persistent storage, but that only protects the stored object, not the permissions, references, or runtime exposure created when a pod mounts or reads it. In practice, the same secret can exist in code, manifests, audit logs, environment variables, and mounted files across the workload lifecycle. The control problem is therefore not whether a secret is encoded once, but whether it is continuously protected across creation, storage, retrieval, and use.

Practical implication: Do not mistake encoding for protection; govern the full secret lifecycle.

Monitoring secret access in Kubernetes clusters

Kubernetes audit logging can record requests against the API server, including secret creation, modification, and access attempts. That gives teams a trace of who requested what, from where, and when, but only if the logs are enabled, retained, and reviewed as part of a broader detection workflow. The article also highlights centralized monitoring, rotation, expiration, and compliance reporting as part of a usable governance model. Technically, the key point is that secret visibility needs to extend beyond inventory into runtime observation, because secrets that are never rotated or never audited remain operationally alive even when they are no longer supposed to be trusted.

Practical implication: Instrument secret access events and rotation status together, not as separate chores.

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 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 governance is NHI governance, not just configuration management. The article makes clear that the object is a carrier for machine credentials, registry access, and service account tokens, which means the identity problem sits inside the cluster, not beside it. Once teams accept that, secret handling becomes a lifecycle and authority question rather than a syntax question. That is the right frame for workload identity programmes.

Base64 encoding has become a dangerous proxy for secrecy. The guide correctly notes that Base64 is reversible and therefore not a control. Too many teams still treat encoded values, or even secret objects in YAML, as if they were inherently protected because they are not in plain text. That assumption fails because disclosure can happen in manifests, logs, environment variables, or mounted volumes long before a credential is formally compromised. Practitioners need to stop counting representation as protection.

Runtime monitoring is the missing governance layer. Kubernetes can expose secrets cleanly while still giving little assurance about who used them, how often, or whether the access pattern was normal. That is why audit trails, access telemetry, and rotation state matter more than the storage format itself. The implication is that teams should govern secrets as active credentials with observable usage, not as static configuration artifacts.

Long-lived service account tokens are a familiar persistence pattern in container estates. The article’s service account and bootstrap token examples show how easily cluster authentication can be made durable. That persistence is useful operationally, but it also extends the window in which misuse matters. Teams should interpret every long-lived secret as an accountability problem, because the credential outlives the event that created it.

Identity blast radius is the right named concept for Kubernetes secret sprawl. When secrets are mounted broadly, reused across pods, or stored without strong usage constraints, one exposed value can unlock more workloads than intended. That is not only a secrets-management issue, it is a blast-radius problem for machine identity. The governing principle is to constrain where a secret can travel and which workload can consume it.

From our research library:

• 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
• 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.

What this signals

Identity blast radius: Kubernetes secret sprawl turns a storage object into a privilege distribution problem, because every additional mount point expands the set of workloads that can act with the same credential. Teams should map each secret to the workload paths that can actually consume it, then narrow that set wherever possible.

The article’s emphasis on audit logging, rotation, and namespace isolation points to a simple but important programme shift: secret management needs operational evidence, not just policy statements. If a team cannot see secret usage over time, it cannot defend the assumption that access is still appropriate.

For Kubernetes programmes, the practical boundary is whether a secret is still being used by the workload that justified it. Once that answer is unclear, the secret should be treated as excess access rather than as harmless configuration.

For practitioners

• Audit hardcoded secret paths Search application code, manifests, Git repos, and CI pipelines for embedded passwords, tokens, and registry credentials, then remove them from source-controlled locations.
• Separate encoding from protection Require encryption at rest and transport-layer protection for secret delivery, and do not treat Base64 values in YAML as a security control.
• Constrain secret exposure by namespace Map each secret to the smallest viable namespace and workload set so that pods outside the intended boundary cannot consume the credential.
• Enable and review audit logs for secret access Track secret creation, updates, and reads through Kubernetes audit logging, then alert on unexpected access patterns and unplanned modifications.
• Rotate long-lived cluster credentials Prioritise service account tokens, registry secrets, and bootstrap tokens that have no clear expiry or offboarding trigger, then shorten their usable lifetime.

Key takeaways

• Kubernetes Secrets reduce exposure in transit and at rest, but they do not become secure simply because they are stored outside application code.
• The highest-risk failure mode is treating Base64, manifests, and default cluster behaviour as proof of governance.
• Teams need rotation, namespace scoping, and audit visibility together if they want secret handling to function as NHI control rather than credential sprawl.

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.
• Bound Service Account Token: A service account token that is tied more closely to a specific pod or workload context. This binding improves traceability and reduces the usefulness of a stolen token, because the token is less transferable and easier to constrain to its intended runtime scope.
• ImagePullSecret: An ImagePullSecret is a credential object that lets Kubernetes authenticate to a private container registry when pulling images. It extends trust beyond the application runtime into image supply and registry access, so its scope and lifecycle need to be managed like any other non-human credential.
• Namespace Isolation: Namespace isolation is the expectation that users or policies restricted to one Kubernetes namespace cannot affect resources or data outside that namespace. It fails when a shared controller executes delegated logic with broader runtime privileges than the author of the request.

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.