Container escape

A container is isolated from its host by kernel features (namespaces and control groups) and a restricted set of capabilities, but that isolation is thin compared with a virtual machine: the container shares the host kernel. An escape uses a weakness in the boundary to reach the host. The recurring routes are a container run as privileged or with dangerous capabilities, a mounted host path or the host’s container socket exposed inside the container, a kernel vulnerability reachable from within, or a writable mount that leads back to the host filesystem. Once on the host, the attacker has left the application’s blast radius and stands on the node, with reach to every other container on it and to the node’s own credentials.

The failure is treating the container boundary as if it were a virtual-machine boundary. On the clusters we test, containers are frequently run with more privilege than they need because it made something work: a privileged flag for a build job, a host mount for logging, the container socket exposed for convenience. From the attacker’s seat, a single application vulnerability in such a container is not a contained event; it is a route to the node, and from the node to the cluster. The severity gap is enormous, and it is decided entirely by whether the container was allowed to reach the host, which is a configuration choice made long before the attack.

We assess node isolation as a first-class question: which containers run privileged or with dangerous capabilities or host mounts, whether the container socket is exposed, and whether the Kubernetes admission controls actually prevent such workloads from being scheduled. Where a foothold exists we demonstrate the escape and the privilege escalation it enables. The finding is written against the configuration that permitted the breakout, with the reachable host access shown. This is part of how we test container and node isolation.