CoursesKubernetes attack & defenseRBAC & privilege escalation

Privilege escalation paths

escalate, bind, impersonate, and the pod path.

Expert35 min · lesson 6 of 15

Kubernetes has a handful of RBAC verbs and grants that are escalation primitives — they let a subject gain permissions beyond what they were given. Knowing them is essential for both the attacker enumerating a path and the defender closing it.

The escalation verbs

Three verbs deserve special fear. escalate on roles lets a subject create or edit a Role with more permissions than they themselves hold — deliberately bypassing the built-in check that normally stops you granting what you lack. bind on a Role or ClusterRole (the role named in a binding roleRef, not the rolebinding object) lets a subject attach that existing role, including cluster-admin, to any subject, escalating without escalate. impersonate lets a subject act as another user, group, or service account, inheriting their permissions outright. A subject with any of these can climb to cluster-admin, so these grants must be treated as effectively administrative.

the escalation primitives
# escalate: write a role MORE powerful than you hold (bypasses the guard).
# bind: attach an existing powerful role to yourself/another subject.
# impersonate: become another (privileged) identity for a request.
# Enumerate who holds them (defender) — these are effectively admin:
kubectl get clusterroles -o json | jq -r '.items[] | select(.rules[]? |
(.verbs[]? | test("escalate|bind|impersonate"))) | .metadata.name'
# Attacker equivalent, if "bind" is held: attach cluster-admin to self.
kubectl create clusterrolebinding pwn --clusterrole=cluster-admin \
--serviceaccount=prod:frontend

The pod-creation and node paths

Beyond the verbs, capability to create pods is an escalation path: a crafted pod can mount a more privileged service-account token, add a hostPath to read node files, or run privileged to reach the host — and from the node, every co-located pod’s token is exposed. This is why admission control (the next section) matters so much: Pod Security Admission and policy engines block the privileged/hostPath pods that turn create-pods into node compromise. Defenders should audit for the escalation verbs and for create on pods, and layer admission policy so that even a subject who can create pods cannot create dangerous ones.

RBAC escalation primitives
the verbs
escalate
write a role beyond your own
bind
attach cluster-admin to a subject
impersonate
become a privileged identity
the pod path
create pods
mount tokens, hostPath, privileged
blocked by admission
PSA/policy stops dangerous pods
escalate/bind/impersonate are administrative in effect; create-pods becomes node compromise unless admission control forbids the dangerous shapes.
escalate, bind, and impersonate are cluster-admin in disguise
A subject holding any of these verbs can climb to full cluster control, yet they read as narrow, technical grants in a RoleBinding. Audit for them explicitly, grant them to essentially no one, and treat any workload service account that holds them as a critical finding.