Every pod in a default Kubernetes cluster gets handed a small file it never asked for. That file is a Kubernetes service account token, and it sits at a fixed path inside the container, ready for any process that can read the filesystem. The token lets the pod talk to the API server, which is fine when the pod needs that. The trouble starts when an attacker who lands code execution in one pod, or who can make that pod issue requests for them, picks the token up and starts walking toward cluster admin. This post takes that walk apart, from the mounted file to the RBAC rights that turn one compromised pod into a foothold across the whole cluster.
Why a pod has a Kubernetes service account token at all
When you create a pod and say nothing about identity, Kubernetes assigns it the default service account in its namespace and mounts that account’s token into the container. Look inside a running pod for our invented cluster at acme.example and you find this:
/var/run/secrets/kubernetes.io/serviceaccount/token /var/run/secrets/kubernetes.io/serviceaccount/ca.crt /var/run/secrets/kubernetes.io/serviceaccount/namespace
The token file holds a signed JSON Web Token, and ca.crt lets the pod trust the API server. The token is a bearer credential, so whoever holds it is treated as the account that owns it, with no second factor. This is reasonable when a pod has a real reason to call the API, for example a controller that watches config maps. The problem is that many pods get a token they never use, because auto mount is on by default, and a credential nobody needs is still one to steal.
From one compromised pod to the API server
An attacker reaches the token in one of two ways. The loud way is code execution: an application bug or a vulnerable dependency gives them a shell, and reading a file is then trivial. The quieter way is server side request forgery, where the app is tricked into making an HTTP request to a destination the attacker chooses. We cover that in our writeup on SSRF, and a third route in container escape. Each ends the same way: the token leaves the pod.
Inside the cluster the API server is reachable at a stable endpoint, exposed through the kubernetes service and environment variables every pod receives, for example KUBERNETES_SERVICE_HOST=10.0.0.1 on port 443. With the token and that address, the request is simple. The token rides in the Authorization header:
GET https://10.0.0.1:443/api/v1/namespaces/acme-prod/secrets Authorization: Bearer <contents of the token file>
If the service account may list secrets in that namespace, the API server answers honestly. It does not care that the request came from a process the attacker now controls. The token is valid, so the call is authorized.
A mounted token is not a secret the way a password is a secret. It is a working key to the API server, sitting in plain sight inside every pod that was told to carry one.
How excessive RBAC turns a token into escalation
A stolen token is only as useful as the rights attached to it. Role based access control, or RBAC, decides what each service account may do, and escalation lives in how generous those rules are. The first move an attacker makes is to ask the API server what the token can do:
kubectl auth can-i --list
That returns the verbs and resources the account holds. A few common over grants and what each buys an attacker:
- list or get on secrets reads every secret in scope, often including database passwords, API keys, and other service account tokens. One read can hand over credentials that reach far past the cluster.
- create on pods lets the attacker launch a pod they design. One that mounts the host filesystem or runs as privileged is a direct route off the node.
- create on rolebindings or clusterrolebindings lets them bind a stronger role to an account they control. Bind
cluster-adminand the walk is over. - create on pods/exec lets them run commands inside other running pods, including ones in other namespaces, spreading sideways.
The worst case is an application service account carrying a wildcard verb on a wildcard resource, or a binding straight to cluster-admin. Then the difference between a contained incident and a full takeover is one stolen token. The token did not gain new rights. It was always a key to whatever RBAC allowed.
The metadata and SSRF angle on managed clusters
On managed clusters there is a second prize. A pod an attacker can steer can often reach the cloud metadata endpoint at the link local address 169.254.169.254, the same endpoint we take apart in our post on the instance metadata service. If the node’s identity is over permissioned, the credentials parked there extend the blast radius into the cloud account. An attacker probing SSRF tries the in cluster API address and the metadata IP in many encoded forms, hoping one slips past a filter. A free in browser tool, the SSRF IP and URL normalizer, shows how those internal addresses can be rewritten, which helps a defender see what a blocklist must catch.
Detecting and preventing the abuse
The fixes stack, and none of them depend on catching every application bug first. Each control shrinks either the chance a token leaks or the damage it does once it has.
Stop mounting tokens that nobody uses
If a pod never calls the API server, it has no reason to carry a token. Turn auto mount off, on the service account or pod spec, so the file is never there to steal:
automountServiceAccountToken: false
This is the highest value single change for the many workloads that never talk to Kubernetes. A token never mounted cannot be read or leaked at all.
Practice least privilege in RBAC
Give each service account only the verbs and resources its job requires, scoped to one namespace where possible. No wildcard verbs, no wildcard resources, and no binding an application account to cluster-admin. Audit the bindings you have, because clusters accumulate broad grants as people copy an example that asked for too much. Read access to secrets deserves a hard look, since one list call drains a namespace.
Use bound, short lived tokens and segment the cluster
Modern Kubernetes issues projected tokens bound to a specific pod that expire on a short clock, so a stolen copy stops working on its own. Prefer those over old style tokens that never expired. Put sensitive workloads in their own namespaces so a foothold in one does not see another’s secrets. Apply a network policy that blocks pod access to the metadata endpoint and restricts egress, so even a steered pod cannot reach 169.254.169.254. The CNCF and the joint NSA and CISA Kubernetes hardening guidance treat these controls as a baseline.
The assumption that breaks
Strip away the JSON and the headers and what is left is one assumption. Kubernetes mounts a Kubernetes service account token because it assumes the only thing reading that file is the pod’s own honest code. An application bug breaks that: the moment an attacker can run code or forge a request inside the pod, they can read anything the pod can read and call anything it can call. The boundary everyone pictured, the wall around the container, was not the one that mattered. The one that mattered ran through an RBAC rule that granted too much. You find that kind of gap by asking what each component trusts and why, not by scanning for a known bad string. There are more teardowns like this on the blog.
This is the class of bug an autonomous researcher that tests an application’s assumptions is built to find. UnboundCompute is early and still being built, so we will say only that it does the honest work of mapping trust. Read more on our about page.
Frequently asked questions
Where does Kubernetes mount the service account token inside a pod?
By default the token is projected into the container at /var/run/secrets/kubernetes.io/serviceaccount/token, alongside ca.crt and a namespace file. It is a signed bearer token, so any process that can read that path can present it to the API server and be treated as the service account that owns it.
How does a stolen service account token lead to escalation?
The token only carries the rights granted to its account through RBAC. If that account has over broad rules such as list on secrets, create on pods, or create on rolebindings, an attacker can read credentials, launch a privileged pod, or bind a stronger role. A binding to cluster-admin turns one stolen token into full cluster control. See the Kubernetes RBAC docs at https://kubernetes.io/docs/reference/access-authn-authz/rbac/.
How do I stop pods from carrying a token they do not need?
Set automountServiceAccountToken to false on the service account or the pod spec for any workload that never calls the API server. A token that was never mounted cannot be read by a shell or leaked through SSRF, which removes the credential from the many pods that have no reason to talk to Kubernetes at all.
Can SSRF in a pod reach the cloud metadata endpoint?
Yes. A pod an attacker can steer through SSRF can often reach both the in cluster API server and the cloud metadata endpoint at 169.254.169.254. If the node identity is over permissioned, the credentials there extend the reach from the cluster into the cloud account. Block the metadata IP with a network policy and restrict egress.