Kubernetes service account tokens expose a long-lived NHI risk

At a glance

What this is: This is a Kubernetes security analysis showing that long-lived service account tokens behave like non-human identities with persistent access and broad compromise potential.

Why it matters: It matters to IAM and NHI practitioners because Kubernetes workloads often inherit access by default, so token lifetime, mount policy, and rotation control become governance issues rather than platform details.

👉 Read GitGuardian's analysis of Kubernetes service account token risks

Context

Kubernetes service account tokens are bearer credentials for workloads, not user passwords, and they can persist far longer than the workload that needs them. In NHI terms, that creates standing access for pods and automation paths that are often under-governed, over-mounted, and difficult to inventory.

The article’s core point is that default convenience in Kubernetes can become an identity risk when tokens are stored as Secrets, copied into CI/CD systems, or inherited by pods that do not actually need API access. That is a typical starting position for many platform teams, which is why the issue matters well beyond Kubernetes administration.

Key questions

Q: How should security teams reduce the risk of Kubernetes service account tokens?

A: Security teams should minimise token exposure by disabling automounting where API access is unnecessary, using short-lived projected credentials where it is required, and enforcing policy that blocks long-lived token Secrets. The key is to treat each workload credential as a governed NHI with ownership, expiry, and revocation, not as an implementation detail.

Q: Why do long-lived Kubernetes tokens create more risk than short-lived ones?

A: Long-lived tokens increase the time an attacker can reuse a stolen credential, which raises the chance of privilege escalation, lateral movement, and persistence. Short-lived tokens shrink the compromise window and make revocation meaningful. In practice, the difference is not just lifespan. It is whether access is tied to current workload state or to a stale trust assumption.

Q: What is the difference between automounting a token and using projected credentials?

A: Automounting places a service account token into a pod by default, which can expose credentials even when the workload does not need them. Projected credentials are issued with a bounded lifetime and are tied more closely to the pod’s runtime. For governance, projected credentials are easier to align with least privilege and lifecycle control.

Q: How can Kubernetes teams tell when a service account token should be revoked?

A: A token should be revoked when the workload is retired, the service account’s purpose changes, or the token has outlived the access it was created to support. Teams should also revoke immediately after suspected exposure. If revocation is not part of the workload lifecycle, the organisation is leaving standing access in place by default.

Technical breakdown

Why long-lived service account tokens create an NHI trust problem

A Kubernetes service account token is a bearer token that authenticates a workload to the API server. Because the token is reusable until it expires, anyone who obtains it can act as that workload within the scope of its permissions. In practice, the token becomes a non-human identity with standing credentials, which is the same failure pattern seen in other secret-based systems. The problem is not Kubernetes alone. It is the assumption that an application identity can remain trusted indefinitely after first issuance.

Practical implication: Treat every service account token as a governed NHI credential with a defined lifetime, ownership, and revocation path.

How token mounting and Secret storage expand blast radius

Kubernetes can automatically mount service account tokens into pods and, in older patterns, store them as long-lived Secrets. That creates multiple exposure paths: shared volumes, misconfigured file permissions, logs, CI/CD artifacts, and compromised containers. Once a token lands in one of those places, it often outlives the original pod. This is why secret sprawl inside a cluster matters. The credential is no longer tied to one runtime instance, so the blast radius becomes the whole namespace or cluster, depending on the bound permissions.

Practical implication: Reduce exposure by disabling unnecessary automounting and limiting where workload credentials can exist at rest and in transit.

What short-lived tokens change in Kubernetes governance

Short-lived tokens shift Kubernetes from static credential inheritance toward time-bounded access. The TokenRequest API and projected volumes let the cluster issue credentials that expire with the pod or with a defined TTL, which makes compromise less durable and rotation more automatable. That does not remove the need for policy, monitoring, or pipeline changes. It simply moves control from a one-time secret issuance model to a lifecycle model. For NHI governance, that is the right direction because access becomes linked to current workload state rather than historical deployment state.

Practical implication: Use TTL-based credentials wherever possible and make rotation failure observable before it becomes an outage.

Threat narrative

Attacker objective: The attacker wants durable Kubernetes API access that can be reused to control workloads, steal data, and maintain persistence inside the cluster.

1. entry via leaked or over-mounted service account token exposed in a repository, log, shared volume, or vulnerable pod.
2. escalation by using the token’s API permissions to enumerate workloads, read Secrets, or modify roles and bindings.
3. impact through persistent cluster access, workload tampering, data exfiltration, or abuse of cluster resources for malicious activity.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

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

NHI Mgmt Group analysis

Standing service account tokens are a classic NHI governance failure. Kubernetes makes it easy to issue workload credentials, but easy issuance is not the same as safe governance. Long-lived tokens create persistent trust without continuous verification, which is exactly the condition ZTA and ZSP try to eliminate. Practitioners should treat these tokens as high-risk NHIs, not just implementation artifacts.

Token lifetime is the real control plane, not token format. Whether a credential is stored as a Secret or projected into a pod, the governance question is how long it remains valid, where it can be mounted, and who can request it. That shifts the debate from deployment convenience to identity blast radius. Teams that ignore lifetime are building static trust into dynamic systems.

Secret sprawl and workload identity sprawl are converging. Kubernetes clusters increasingly sit at the centre of CI/CD, automation, and application delivery, which means one leaked token can become many compromised actions. This is where NHI governance must join platform governance. The practical conclusion is simple: if a workload does not need API access, it should not receive a token.

Kyverno-style policy enforcement shows the right governance pattern. Preventing long-lived service account tokens at the policy layer is better than relying on team-by-team discipline. Policy gives security teams a repeatable control point for enforcing posture across clusters, especially where application teams would otherwise reintroduce standing access for convenience. The takeaway for practitioners is to make token denial a default control, not an exception review.

Short-lived credentials align Kubernetes with modern identity governance. The direction of travel in NHI security is toward ephemeral access, clear ownership, and fast revocation when workloads change or disappear. Kubernetes already has the primitives to support that model, but many environments still operate as if static credentials are acceptable. Practitioners should re-evaluate whether their cluster design still assumes permanent trust in transient workloads.

From our research:

• 64% of valid secrets leaked in 2022 are still valid and exploitable today, according to the State of Secrets Sprawl 2026.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
• For the broader pattern behind Kubernetes token exposure, see Guide to the Secret Sprawl Challenge for how leakage, persistence, and revocation failures combine.

What this signals

Ephemeral credentials are becoming the baseline expectation for NHI governance. Kubernetes teams that still rely on static service account tokens are carrying forward an access model that no longer matches how modern workloads are deployed or retired. With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the wider trend is clear: discovery without revocation is not a control strategy. Practitioners should align cluster identity design with NIST Cybersecurity Framework 2.0 and shorten the lifetime of every workload credential that does not need to persist.

Identity blast radius should become a standard design metric. In Kubernetes, the question is not only whether a token exists, but how far it can move if it is copied, mounted, or logged. That is why workload identity policy should sit alongside platform engineering decisions, not after them. Teams that use service accounts for CI/CD and automation should also evaluate the control patterns in the OWASP NHI Top 10 when building policy for autonomous or semi-autonomous workloads.

For practitioners

• Disable unnecessary service account automounting Set automountServiceAccountToken to false for pods and service accounts that do not need Kubernetes API access. This removes a major exposure path for credentials that would otherwise be mounted by default and reduces the chance that a compromised container can reuse an inherited token.
• Move to short-lived projected credentials Prefer the TokenRequest API and projected volumes for workloads that must call the Kubernetes API. Tie token lifetime to pod life or a narrowly defined TTL, then verify that renewal, expiry handling, and workload retries are instrumented before rollout.
• Enforce token-denial policy at cluster level Use admission control or policy engines such as Kyverno to block creation of kubernetes.io/service-account-token Secrets. This prevents teams from reintroducing long-lived tokens through local exceptions or legacy deployment paths.
• Review CI/CD paths for workload credential exposure Audit build runners, deployment jobs, and logging pipelines for places where tokens can be copied, cached, or printed. CI/CD is often where Kubernetes NHIs become visible to attackers after an otherwise ordinary deployment workflow.
• Map token ownership to workload lifecycle Require every token-bearing service account to have an owner, a purpose, and a retirement condition. If a workload is decommissioned, its credentials should be invalidated as part of the same change window rather than left behind as dormant access.

Key takeaways

• Kubernetes service account tokens are non-human identities with standing access, which makes token lifetime a governance issue rather than a platform convenience.
• Leaked or over-mounted tokens can be reused for escalation, persistence, and workload abuse, so the exposure window matters as much as the original secret control.
• Policy enforcement, short-lived credentials, and workload-aware revocation are the controls that move Kubernetes identity management toward least privilege.

Key terms

• Service Account Token: A service account token is a bearer credential that lets a Kubernetes workload authenticate to the API server. It represents non-human access, so whoever holds it can act as the workload within its granted permissions until the token expires or is revoked.
• Projected Volume Token: A projected volume token is a Kubernetes credential delivered into a pod with a bounded lifetime rather than stored indefinitely as a Secret. It supports a more modern lifecycle model because the token is tied to the pod and can be rotated or invalidated automatically.
• Automounting: Automounting is the default Kubernetes behaviour that places a service account token into a pod when the workload starts. It is convenient, but it can expose credentials to workloads that do not need API access and increases the chance of accidental token reuse.
• Identity Blast Radius: Identity blast radius is the amount of damage an attacker can do after compromising a single credential. In Kubernetes, it depends on token lifetime, permission scope, and where the credential is mounted or copied, which makes it a practical measure of workload identity risk.

What's in the full article

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

• Step-by-step Kyverno policy syntax for blocking kubernetes.io/service-account-token Secrets
• Example Kubernetes manifests showing how to disable automounting at the service account and pod level
• Operational trade-offs for short-lived token renewal, including pipeline retries and monitoring requirements
• Hands-on mitigation patterns using secret managers and service mesh components for token lifecycle handling

👉 GitGuardian's full post covers the lifecycle risks, mitigation patterns, and Kyverno policy example in more detail

Deepen your knowledge

Kubernetes service account token governance is covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your teams are still relying on static workload credentials, it is worth exploring.