The Kubernetes TokenRequest API mints short-lived, scoped service-account tokens on demand. An attacker who compromises a pod or identity that can call it can request fresh tokens for other service accounts, for example a CSI driver, extending access and evading detection that watches for static, long-lived tokens. Defend by scoping TokenRequest permissions tightly and monitoring token minting.
What Kubernetes TokenRequest abuse is
TokenRequest is the modern way Kubernetes issues service-account tokens: instead of long-lived secrets, the API mints short-lived, audience-scoped tokens on demand, projected into pods. The permission to create these tokens is powerful, because whoever holds it can mint credentials for the service accounts it covers.
How it works and example
An attacker who takes over a pod identity that can call TokenRequest, such as a CSI driver pod, uses it to mint fresh tokens for privileged service accounts. The new tokens are valid and short-lived, so credential-theft detection tuned for static secrets does not flag them, and the attacker refreshes access as needed. This was part of a 2026 machine-speed Kubernetes intrusion.
How to defend against it
Scope the create verb on serviceaccounts/token with least-privilege RBAC so few identities can mint tokens, and never grant it broadly. Audit token requests, keep token TTLs short and audience-bound, bind tokens to the requesting pod, and alert on token minting from unexpected identities or at unusual rates.
References
- [1]MITRE ATT&CK Cloud Matrix(MITRE ATT&CK)
- [2]HuggingFace, Agent intrusion technical timeline(HuggingFace)
- [3]Kubernetes TokenRequest API(Kubernetes)
If too many identities can mint service-account tokens, one compromise mints many. Talk to a security expert about auditing your cluster RBAC.