Auditing Kubernetes RBAC Privilege Escalation

Legal Notice: This skill is for authorized security testing and educational purposes only. Enumerating and exercising RBAC permissions affects a live cluster's access posture. Only test clusters you own or are explicitly authorized in writing to assess.

Overview

Kubernetes Role-Based Access Control (RBAC, MITRE ATT&CK T1078 Valid Accounts) governs what every user and service account may do via Role/ClusterRole rules bound by RoleBinding/ClusterRoleBinding. Because workloads run with a mounted service-account token by default, an attacker who compromises one pod inherits that account's RBAC rights. Over-permissive bindings turn a single compromised pod into a cluster takeover: certain verbs and resources are "RBAC-equivalent to cluster-admin."

Per the Kubernetes "RBAC Good Practices" guidance and Unit 42 research, the dangerous primitives are:

• escalate on roles — grant yourself any permission, even ones you do not hold.
• bind on clusterroles — create a binding to cluster-admin.
• impersonate on users/groups/serviceaccounts — act as any subject including system:masters.
• create/update/patch on pods — schedule a privileged pod or mount the node, escaping to the host (T1611).
• create on pods/exec, pods/attach, pods/ephemeralcontainers — run code in any existing pod.
• get/list/watch on secrets — list returns full secret contents, including other service-account tokens.
• create on serviceaccounts/token — mint tokens for more privileged accounts.
• update/patch on validatingwebhookconfigurations/mutatingwebhookconfigurations, nodes/proxy, certificatesigningrequests/approval — admission/CSR abuse to cluster-admin.
• Wildcards (verbs: ["*"], resources: ["*"]) — implicit super-privilege.