RBAC & the powerful grants

secrets, pods create, exec — escalation in disguise.

RBAC is the cluster’s authorization core, and most Kubernetes privilege escalation is really an RBAC misconfiguration. Understanding exactly what verbs and resources grant — and which ones grant far more than they appear to — is the foundation of both attack and defense.

The model and the deceptively-powerful grants

An RBAC rule grants verbs (get, list, watch, create, update, patch, delete) on resources, bound to a subject by a RoleBinding (namespaced) or ClusterRoleBinding (cluster-wide). The trap is that some grants are far more powerful than they look. get/list on Secrets returns every credential in plaintext. create on pods lets a subject mount any service-account token, add a hostPath, or run privileged — a direct path toward the node. The pods/exec subresource runs arbitrary commands in a running pod and reaches its secrets. Reviewing RBAC means recognizing these high-impact grants, not just counting bindings.

# Enumerate a subject's effective permissions (as an attacker or a reviewer):
kubectl auth can-i --list --as=system:serviceaccount:prod:frontend
 
# Hunt cluster-wide for the dangerous grants:
kubectl get clusterrolebindings -o json | jq '.items[] |
  select(.roleRef.name=="cluster-admin") | .subjects'      # who is cluster-admin?
# Also review any Role/ClusterRole granting: secrets get/list, pods create,
# pods/exec, and the escalation verbs (next lesson).

Least privilege in practice

Least-privilege RBAC means scoped roles, a dedicated service account per workload, and no wildcards (resources: "*" or verbs: "*"). Prefer namespaced Roles over ClusterRoles, grant only the specific verbs and resources a workload actually uses, and never reuse the default service account for pods that talk to the API. The payoff is containment: when a pod is compromised, its token opens only the few doors you deliberately granted, not the whole cluster. RBAC hygiene is the single highest-leverage cluster-security control.