Kubernetes access privilege escalation

Kubernetes access privilege escalation is one of the most dangerous and overlooked threats in containerized environments. It happens when a low-privilege account gains higher permissions than intended. This can happen through excessive role assignments, namespace-wide privileges, service account token exposure, or improperly scoped bindings. Once escalated, an attacker can deploy workloads, exfiltrate secrets, or disrupt cluster operations.

The Kubernetes RBAC system is powerful, but it is also easy to misuse. Overprovisioned ClusterRoles, wildcard verbs, and blanket access to sensitive API groups allow privilege escalation pathways. Service accounts with edit or admin roles in sensitive namespaces often lead directly to cluster compromise. Nodes, kubelets, and admission controllers can also be targeted if access is broadened beyond what is required.

Common escalation techniques include:

• Accessing the API server using a leaked service account token.
• Exploiting create pod permissions to mount host paths or run high-privilege containers.
• Leveraging impersonation rights via impersonate verb assignments.
• Modifying RoleBindings to grant oneself admin privileges.

Preventing Kubernetes access privilege escalation requires strict RBAC design. Apply the principle of least privilege. Avoid namespace-wide admin roles unless strictly necessary. Regularly audit RoleBindings, ClusterRoleBindings, and service account permissions. Use admission controllers to enforce policy and prevent risky configuration changes. Scan manifests before deployment, and monitor API calls for suspicious activity.

A Red Team only needs one privilege gap to own the cluster. Close that gap before they find it.

See how hoop.dev lets you test, detect, and fix Kubernetes access privilege escalation paths—live and in minutes.