A pod that talks its way to cluster admin (GKE RBAC)
A compromised pod with a permissive Kubernetes role, or access to the node's service account, can escalate to control the whole GKE cluster. Here is the path from one container to cluster-admin, and the fix.
One container should not be able to rewrite who is allowed to do what across the whole cluster. Too often it can.
What it is
In GKE, pods authenticate to the Kubernetes API with a service account, and Kubernetes RBAC governs what each can do. An attacker who compromises a pod with an over-permissive Role (for example, the ability to create pods, read secrets, or bind roles), or who reaches the node’s GCP service account via the metadata server, escalates to cluster-admin, then controls every workload and can pivot into the GCP project. This is T1078 (valid accounts) with T1548 (abuse elevation control mechanism).
Why it works
RBAC is easy to grant too broadly, secret-read or pod-create rights are effectively escalation, and a node’s service account is often more privileged than any pod should reach.
How to detect it
In the Kubernetes audit logs, look for a service account creating roles or bindings, reading many secrets, or creating privileged pods, and pods reaching the node metadata endpoint.
The fix that holds
Least-privilege RBAC (no wildcard or role-binding permissions for workloads), Workload Identity so pods use scoped GCP identities instead of the node service account, block pod access to the metadata server, and apply pod security standards. Alert on RBAC changes and secret enumeration.
Practice it
We built a GKE RBAC escalation scenario in GraphLattice Range so teams learn the pod-to-cluster-admin path and how to cut it.