Kubernetes VAPT: RBAC Attack Paths and Container Escape
June 4, 2026
Kubernetes is the dominant container orchestration platform, and Kubernetes clusters have become one of the most complex targets for defensive VAPT programmes to assess. The complexity emerges from the interaction of multiple authorization layers, the pluggable nature of the platform, and the reality that most production clusters accumulate misconfigurations gradually as teams add workloads with expedient permissions. This document describes a systematic Kubernetes VAPT approach organised around the escalation paths that consistently appear in production clusters.
Assessing the Initial Access Surface
A defensive Kubernetes assessment models the possible initial access vectors as the starting points for escalation analysis. The relevant vectors include compromised container images pulled from untrusted registries, application-layer vulnerabilities in workloads exposed to external traffic, misconfigured Kubernetes API server exposure that permits unauthenticated access, exposed etcd instances that provide direct database access to the cluster state, and supply chain compromise of dependencies loaded into containerised workloads.
For each modelled initial access vector, the assessment characterises the starting position an attacker would reach — process context, filesystem access, network reachability, and any credentials or tokens available in the environment. The characterisation is essential input to the subsequent escalation analysis because the escalation paths available depend heavily on what the initial access provides. Compromise of an unprivileged container with a service account token yields different escalation paths than compromise of a privileged container without a service account token.
The assessment also includes external exposure analysis of the Kubernetes API server, ingress controllers, and administrative interfaces. Kubernetes API servers exposed to the internet with insufficient authentication have been the initial access vector for a large fraction of documented Kubernetes compromises. Ingress controllers with misconfigured annotations that permit path traversal or authentication bypass are a similarly common surface. Direct API access from unexpected network segments (developer laptops, CI/CD systems with excessive network reachability) should be enumerated and reviewed against documented access policies.
Service Account Token Analysis
Every pod runs under a Kubernetes service account, and by default the service account token is mounted into the pod filesystem at a well-known path. Applications that don't explicitly need to talk to the Kubernetes API still receive this token, which provides authenticated API access to the cluster with whatever permissions the service account has. Assessments should enumerate every pod and its associated service account, then evaluate the permissions each service account holds via role bindings.
Service accounts frequently accumulate permissions beyond what the workload actually needs. Applications that were initially granted broad permissions during development often retain those permissions in production because retracting them requires understanding what would break. A defensive assessment produces the permission inventory that enables safe permission reduction; the assessment output is not just a list of over-permissioned service accounts but a recommendation for the minimum permissions each workload actually requires based on observed usage.
The default behaviour of automounting service account tokens can be disabled per-pod or per-service-account. Workloads that do not need Kubernetes API access should have automounting disabled — this eliminates the token exposure surface entirely for those workloads. Assessments should identify workloads that do not appear to use Kubernetes API access and recommend disabling automounting as a defence-in-depth control that costs nothing operationally while removing a common escalation path.
RBAC Configuration and the Path to Cluster Admin
Kubernetes RBAC (Role-Based Access Control) is the primary authorization mechanism, and RBAC misconfigurations are the most common escalation surface within compromised clusters. Specific permissions permit privilege escalation without any additional vulnerabilities: the ability to create pods with arbitrary specifications, the ability to modify existing pods, the ability to exec into other pods, the ability to bind roles, and the ability to modify secrets are all documented escalation vectors when granted to accounts that should not have them.
The ability to create pods, in particular, is effectively equivalent to node-level access on any node the pod can be scheduled to. An account with pod creation permission can create a pod with host filesystem mounts, privileged security context, or host network access — each of which provides mechanisms to reach node-level credentials that then extend cluster access. Assessments enumerate every account that can create pods and evaluate whether any admission controllers constrain the pod specifications those accounts can submit.
Cluster-scoped bindings deserve particular attention. RoleBindings are namespace-scoped and limit escalation to a single namespace, but ClusterRoleBindings apply across the cluster. A ClusterRoleBinding that grants pod-creation permission across all namespaces is a substantially larger risk than a RoleBinding granting the same permission in one namespace. Assessments should distinguish namespace-scoped from cluster-scoped bindings when reporting findings because the remediation approaches and impact assessments differ.
Pod Security Standards and Admission Control
Pod Security Standards (PSS) define baseline security requirements for pod specifications — restricting privileged containers, host filesystem mounts, host network access, and other high-risk options. Pod Security Admission enforces PSS at admission time, rejecting pod specifications that violate the standards. A defensive Kubernetes assessment evaluates whether Pod Security Admission is configured, at what enforcement level, and whether any namespaces are exempted from enforcement.
Third-party admission controllers — OPA Gatekeeper, Kyverno, or custom admission webhooks — extend the enforcement surface beyond what Pod Security Admission provides. Assessments should enumerate every admission controller in use, review the policies each enforces, and identify gaps between the enforced policies and the organisation's stated security requirements. Admission controllers that are deployed but configured in audit-only mode provide no enforcement despite their operational presence.
The interaction between admission controllers and RBAC is important. Admission controllers apply to admission of API requests, and the RBAC permission to bypass admission (typically limited to system:masters group members) undermines admission-based defences for any account with that permission. Assessments should enumerate accounts with admission-bypass permissions and treat their existence as an escalation surface even when the admission policies themselves are well-configured.
Container Escape Considerations
Container escape — obtaining code execution on the underlying node from inside a container — has historically been difficult when containers are configured with default restrictions. Privileged containers, containers with host filesystem mounts, containers with host network access, and containers with dangerous Linux capabilities substantially reduce the difficulty. Assessments enumerate container security contexts across the cluster and identify pods running with configurations that increase escape risk.
Container runtime vulnerabilities occasionally introduce escape paths even from well-configured containers. Historical vulnerabilities in runc, containerd, and CRI-O have periodically produced escape paths that require no unusual container configuration. Runtime patch status is part of a defensive assessment; nodes running unpatched container runtime versions with known escape vulnerabilities represent immediate remediation targets even if no misconfigured containers are deployed.
Kernel version and cgroup configuration on the underlying nodes also contribute to escape resistance. Modern container security features — user namespaces, seccomp filters, AppArmor or SELinux confinement — provide defence-in-depth that raises the difficulty of escape attempts even when other configurations are imperfect. Assessments should identify whether these features are configured and whether specific workloads are exempted from confinement.
Network Policy Coverage and East-West Traffic
Kubernetes network policies restrict pod-to-pod communication within the cluster. In their absence, any pod can communicate with any other pod, and initial compromise of a low-value workload provides network access to every workload the cluster hosts. A defensive assessment evaluates network policy coverage — what fraction of workloads are protected by explicit network policies versus relying on default-open behaviour.
Default-deny network policies at the namespace level, with explicit allow policies for legitimate traffic, provide the strongest posture. Assessments should identify namespaces without any network policies (which default to open) and recommend the incremental adoption of default-deny plus explicit allows. The operational challenge is discovering the legitimate traffic patterns to encode as allow rules; network flow monitoring tools that observe actual traffic before policy enforcement is engaged provide the necessary input.
Service mesh deployments — Istio, Linkerd, or equivalent — provide additional east-west traffic controls including mutual TLS, authorization policies, and observability. Assessments of clusters running service meshes should evaluate whether the mesh is configured to enforce mTLS for all workload communication, whether authorization policies exist for sensitive workloads, and whether workloads bypassing the mesh (via direct pod-to-pod communication) have been identified and either brought into the mesh or explicitly excepted with documented justification.