Privilege escalation in Kubernetes through kubectl is not theory. It happens. One misconfigured RoleBinding, one overlooked ServiceAccount, and the entire security model collapses. The simplicity of kubectl makes it powerful, but in the wrong context, it’s the shortest path from user to cluster admin.
Attackers exploit kubectl privilege escalation by chaining permissions in ways that are easy to miss during audits. Even when RBAC seems locked down, a single exec or impersonate verb on sensitive resources is enough to bypass restrictions. Misuse of kubectl commands like kubectl exec, kubectl create, or kubectl apply can lead to running arbitrary code inside pods, mounting secrets, or reconfiguring high-privilege workloads.
The danger lies in the intersection of kubectl’s broad functionality and the complexity of Kubernetes role-based access controls. A user allowed to create Pods may spin up one with a service account token mapped from a privileged namespace. A user allowed to exec into containers can reach secret volumes. A user with get and list access to certain resources can craft YAML that elevates their permissions.