create pods
Setting serviceAccountName to a privileged SA mounts its token into the pod.
Reading it lets you reuse the SA's identity.
Contextual upgrade to T0:
Permission covers kube-system and pod is configured to run as a high-privilege controller ServiceAccount (e.g. kube-controller-manager), exposing near-cluster-admin credentials
- API Group
- (core)
- Scope
- namespaced
- Audit Level
- Request
Escalation Paths
Create a workload with serviceAccountName set to a privileged ServiceAccount in the same namespace.
Any controller-backed kind works, since the controller creates the pod.
The token is mounted at /var/run/secrets/kubernetes.io/serviceaccount/token, or projected explicitly by the manifest.
Reading it back needs a channel, and the cheapest costs no RBAC at all: the container sends the token outbound itself.
This is why removing pods/log does not close the path.
With get on pods/log, the container prints the token to stdout and the attacker reads it back.
With get on pods, the container writes the token to /dev/termination-log and the attacker reads terminated.message from the pod's status, with no pods/log needed.
Authenticate as the ServiceAccount with the stolen token.
Additional rights needed: