A Kubernetes service account token is a credential mounted into a pod (by default at /var/run/secrets/kubernetes.io/serviceaccount/token) that the pod uses to authenticate to the API server. Its power is whatever RBAC grants that service account. When an attacker gets code execution in a pod, the token is the first thing they steal: they read it from disk and use it to query and act on the cluster. Over-permissioned tokens and unnecessary automounting are the core risk.
What a service account token is
Workloads often need to talk to the Kubernetes API server (to read config, list services, and so on). They authenticate with a service account, and the account’s token is mounted into the pod automatically by default.
The token itself is just a bearer credential; what matters is the RBAC attached to its service account. A token for a tightly scoped account is low risk; a token for an over-permissioned one is a master key.
The abuse and payload
After getting code execution in a pod, the attacker grabs and uses the token:
- Read it:
cat /var/run/secrets/kubernetes.io/serviceaccount/token(plus the namespace and CA in the same directory). - Use it against the API server:
kubectl --token=$TOK --server=https://API auth can-i --listto enumerate what it can do. - If RBAC is broad, list/read secrets, create pods, or otherwise escalate toward cluster control.
Documented techniques shown for defenders.
How to defend
- Disable token automount where a pod does not need the API (
automountServiceAccountToken: false). - Scope each service account with least-privilege RBAC; never bind cluster-admin.
- Use short-lived, audience-bound projected tokens rather than long-lived ones.
- Give each workload its own service account, not a shared or default one.
- Detect unexpected API calls from pod tokens and test the cluster for token-based escalation.
References
- [1]Kubernetes docs: Configure service accounts(Kubernetes)
- [2]MITRE ATT&CK: Containers Matrix(MITRE)
- [3]NIST SP 800-190 Application Container Security Guide(NIST)