Topic starter
15/12/2025 3:45 pm
TL;DR: GitGuardian warns that Kubernetes service account tokens are bearer credentials that can persist indefinitely as Secrets, be mounted into pods, and leak through repositories, logs, network paths, or vulnerable workloads, creating a long-lived NHI risk for cluster access. Short-lived tokens, automount restrictions, and enforced policy controls narrow the attack window but require rotation and pipeline changes.
Editorial analysis by NHI Mgmt Group, based on content published by GitGuardian: “Understanding the Risks of Long-Lived Kubernetes Service Account Tokens”.
Key questions
A: Secret-based service account tokens increase credential sprawl and leave more long-lived credentials lying around than necessary.
Q: Why does relying on long lived secret based service account tokens increase Kubernetes risk?
A: Long lived secret based tokens increase risk because they remain usable far beyond the workload session that created them.
Q: How do security teams know if service account governance is actually working?
A: Governance is working when every service account has an owner, a workload, a retirement condition, and an auditable rotation path.
Practitioner guidance
- Disable unnecessary token automounting Set automountServiceAccountToken to false on service accounts and pods that do not need Kubernetes API access, and enforce that choice consistently across namespaces.
- Adopt short-lived projected tokens Use TokenRequest-based projected volumes where workloads need API access, so credentials expire with the pod rather than persisting as indefinitely valid Secrets.
- Block creation of long-lived token Secrets Apply cluster policy that denies kubernetes.io/service-account-token Secret creation so service account credentials cannot be created as durable static Secrets.
Bottom line: Long-lived Kubernetes service account tokens create a reusable non-human identity path that can survive beyond the workload that requested it.
What's in the full article
GitGuardian's full blog post covers the operational detail this post intentionally leaves for the source:
- The Kubernetes-specific examples of where long-lived service account tokens can leak in real deployments
- The full Kyverno policy pattern used to deny kubernetes.io/service-account-token Secrets
- The trade-offs involved in token renewal, monitoring, and CI/CD pipeline changes
- The article's walkthrough of short-lived token handling with the TokenRequest API
👉 Read GitGuardian's analysis of Kubernetes service account token risk →
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
07/10/2026 6:25 pm
Long-lived service account tokens create identity persistence that outlives the workload that requested them. The article is not really about Kubernetes convenience versus inconvenience; it is about a non-human credential that remains valid after the operational moment that justified it has passed. That makes compromise recovery harder because the credential may still be accepted long after the originating pod, pipeline, or task has changed. For NHI governance, persistence is the problem space, not merely storage location.
A few things that frame the scale:
- Red Hat’s Kubernetes Security Report found that nearly 9 in 10 organizations had at least 1 container or Kubernetes security incident in the last 12 months.
A question worth separating out:
Q: What should organisations do when a Kubernetes service account token is exposed?
A: Treat it as a reusable bearer credential and revoke or replace it immediately, then trace where it was mounted, copied, or logged. The goal is to cut off reuse before the token can be used for workload changes, privilege escalation, or persistence inside the cluster.
👉 Read our full editorial: Kubernetes service account tokens expose a long-lived NHI risk