Kubernetes Privilege Escalation Review

Kubernetes Privilege Escalation Review is the systematic examination of a cluster's RBAC configuration, workload permissions, and pod security settings to identify paths by which an identity with limited access could obtain broader access than it was intended to hold. Escalation can occur through RBAC object manipulation, through workload-level container privileges, or through interactions between the two, and a thorough review considers all three categories rather than treating RBAC and pod security as unrelated concerns.

RBAC-Level Escalation Paths

Direct Role and Binding Manipulation

A subject holding write access to Role, ClusterRole, RoleBinding, or ClusterRoleBinding objects can, absent additional safeguards, create a new role granting itself broader permissions and bind it to its own identity. Kubernetes' built-in escalation prevention blocks this by default — a subject cannot grant permissions beyond what they already hold — unless the subject also holds the escalate or bind verb, which specifically bypasses this protection.

rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["escalate"]

Reviewing every grant of escalate and bind across the cluster, and confirming each one is held only by identities that genuinely need to administer RBAC itself, is one of the highest-value checks in a privilege escalation review.

Impersonation as an Escalation Vector

A subject with unrestricted impersonate access on users or groups — particularly a group like system:masters — can impersonate a more privileged identity on any request, achieving the same practical outcome as holding that identity's permissions directly, regardless of the subject's own nominal role.

Secrets Access as Indirect Escalation

Read access to Secret objects across a namespace or cluster frequently grants indirect escalation, since secrets commonly contain service account tokens, credentials for other systems, or webhook configuration that itself grants further access — a review should trace what a given secrets grant actually exposes, not just treat it as a bounded, low-risk read permission.

Workload-Level Escalation Paths

Privileged Containers and Host Access

A pod running with privileged: true, hostPID: true, hostNetwork: true, or a hostPath volume mounted at a sensitive path can access or manipulate the underlying node directly, frequently allowing an attacker who compromises that container to reach every other workload scheduled on the same node, regardless of that workload's own RBAC scope.

securityContext:
  privileged: true      # flag this during review

The allowPrivilegeEscalation Field

Kubernetes exposes an explicit allowPrivilegeEscalation setting in a container's security context; when true (the default in the absence of a Pod Security Standard enforcing otherwise), a process can gain more privileges than its parent process, for instance through a setuid binary, independent of whatever the container's own configured user and capabilities suggest.

securityContext:
  allowPrivilegeEscalation: false

Node Access via the Node Authorizer's Boundaries

While the built-in Node authorizer restricts kubelets to resources related to their own scheduled pods, a compromised kubelet or node still exposes every secret and service account token mounted into every pod on that node, making node compromise itself a significant escalation path that a review should consider alongside pure RBAC analysis.

Reviewing Service Account Token Reachability

Mounted Tokens as Escalation Fuel

A pod whose service account holds broader permissions than the workload itself requires effectively hands an attacker who gains code execution in that pod all of those broader permissions; reviewing the intersection of "which service accounts are mounted into which pods" against "what those service accounts can do" surfaces escalation paths that reviewing RBAC bindings alone would miss.

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.serviceAccountName}{"\n"}{end}'

Conducting the Review

Static Analysis Tooling

Automated RBAC analysis tools can enumerate every path by which a given identity could reach cluster-admin-equivalent access, tracing chains of escalate, bind, impersonate, and secret access that would be impractical to trace manually across a cluster with hundreds of roles and bindings.

Prioritizing by Reachability

Not every theoretical escalation path is equally reachable; prioritizing paths that start from an identity an external attacker could plausibly compromise first — an internet-facing workload's service account, for instance — over paths that start from an already highly-trusted administrative identity focuses review effort where it has the most practical value.