Container escapes happen because Kubernetes gives cluster administrators many ways to grant permissions that break the isolation boundary between a container and the host. Privileged containers, hostPath mounts, and overly permissive RBAC are not kernel exploits. They are misconfigurations that Kubernetes allows by default and attackers use to move from a compromised pod to full cluster control.
Analysis Briefing
- Topic: Container escape and Kubernetes privilege escalation attack paths
- Analyst: Mike D (@MrComputerScience)
- Context: A research sprint initiated by Perplexity AI
- Source: Pithy Security
- Key Question: What does an attacker do the moment they compromise a Kubernetes pod?
How Privileged Containers Eliminate the Isolation Boundary
A container running with privileged: true in its security context has full access to the host’s devices and kernel capabilities. It can mount the host file system, load kernel modules, and interact with the Docker or containerd socket. The isolation that containers normally provide is completely absent.
Attackers who compromise a privileged container can mount the host root file system and write a cron job or SSH key directly. They can access the container runtime socket and launch new privileged containers with arbitrary configurations. From a privileged container, the host is fully accessible.
Privileged containers exist in legitimate workloads: CNI plugins, storage drivers, and some monitoring agents require elevated access. The problem is that privileged: true is often added by developers to fix a permission error without understanding what it grants.
Why hostPath Mounts Give Attackers Host File System Access
The hostPath volume type mounts a directory from the node’s file system directly into a container. A pod with a hostPath mount to / has read and write access to the entire host file system from inside the container without being privileged.
An attacker who compromises a pod with a hostPath mount to /var/run/docker.sock or /run/containerd/containerd.sock controls the container runtime. They can launch new containers with any configuration, including privileged containers, host network access, or volume mounts to sensitive host paths.
CISA and NSA’s Kubernetes hardening guide explicitly identifies hostPath mounts as a high-risk configuration and recommends Admission Controllers that block them for non-system workloads.
When Kubernetes RBAC Misconfigurations Enable Cluster Takeover
RBAC escalation is often the path attackers take after compromising a pod without direct host access. Overly permissive service account bindings give pods the ability to create new pods, list secrets, or modify cluster roles. Any of these permissions can be escalated to full cluster control.
A pod with permission to create pods can create a privileged pod on any node. A pod with get secrets permission on the kube-system namespace can read the cluster admin service account token. The kubectl auth can-i --list command from inside a compromised pod reveals every permission the pod’s service account holds.
The principle of least privilege for Kubernetes service accounts means giving each workload only the RBAC permissions it genuinely needs, with no default cluster-admin bindings for application workloads.
What This Means For You
- Audit every pod spec for
privileged: trueand replace it with specific capabilities usingsecurityContext.capabilities.addfor the minimum set the workload actually requires. - Deploy an Admission Controller like OPA Gatekeeper or Kyverno that enforces a baseline policy blocking privileged containers and sensitive
hostPathmounts across the cluster before workloads deploy. - Run
kubectl auth can-i --listfrom within your pods to audit what your service accounts can actually do, because RBAC misconfigurations that enable cluster takeover are often invisible until you check from the pod’s perspective. - Restrict access to the container runtime socket using file system permissions and pod security admission, because socket access from a container provides container escape without any kernel vulnerability required.
Enjoyed this deep dive? Join my inner circle:
- Pithy Security → Stay ahead of cybersecurity threats.