Container escapes typically occur when a container gains direct access to host resources due to excessive permissions or shared namespaces. I'm working on a few Github projects to explore these risky misconfigurations in reproducible PoCs. The 3 categories of risk I'm exploring that commonly lead to container escapes are:
- Dangerous volume mounts
- Linux capabilities
- Shared namespaces
Dangerous volume mounting (like hostPath) is when a developer mounts a directory from the underlying host filesystems like /, /var/run/docker.sock or /etc directly into a container. The risk here is if a container mounts the host root / filesystem or sensitive sockets like any sort of container runtime socket, a process inside the container can now interact directly with the host OS or manage container runtimes, effectively bypassing container isolation.
Github reference:
https://github.com/ndouglas-edera/hostpath-risk
Linux capabilities (like CAP_SYS_ADMIN and CAP_SYS_PTRACE) are granular administrative privileges assigned to processes within a container. The risk here is that capabilities like CAP_SYS_ADMIN allow actions such as mounting filesystems, setting network configs, or even interacting with kernel interfaces, ultimately enabling container processes to break out of their Linux namespaces.
Github reference:
https://github.com/ndouglas-edera/CAP_SYS_ADMIN-Escape
Shared namespaces (like hostPID, hostNetwork, and hostIPC) end up disabling the standard namespace separations between the container and the underlying node. It's ultimately risky because it allows containers to interact with host processes, inter-process communication channels, or raw network interfaces, breaking isolation between workloads on the same node.
Github reference:
https://github.com/ndouglas-edera/hostpid-risk
How isolated runtimes can mitigate these risks
The above scripts I provided on Github were purely to automate the demonstration of these existing insecure configurations within Kubernetes. Since standard containerised workloads rely on various shared host Linux kernel features, such as namespaces and cgroups, to enforce boundaries - if a container ends up gaining elevated privileges or access to host resource, it now operates directly on that shared kernel. Secure runtime solutions like Edera Zones, Kata Containers, and gVisor change this threat model by providing secure (MicroVM) sandboxing layers. Instead of sharing the host kernel, workloads run inside lightweight VMs with their own isolated kernel. Similarly, even if a process inside the sandbox achieves privileged: true or mounts a volume, its actions are constrained to its own guest kernel. Escaping the container only grants access to the isolated microVM environment, preventing access to the host OS, host memory, or adjacent workloads on the node. Finally, direct access to host process IDs or raw host sockets is prevented because the guest kernel maintains an entirely separate execution environment from the host operating system. I'm going to continue fleshing-out these repos to show how these misconfigurations are common place, but also how to address them within a single-node test sandbox like EderaOn.