Why Container Isolation Is Not the Same as VM Isolation
A Virtual Machine (VM) runs its own complete operating system kernel on top of a hypervisor. If a bug exists in the guest kernel, it affects only that VM. The hypervisor provides a hard boundary enforced by hardware virtualization extensions (Intel VT-x, AMD-V).
Containers work differently. Standard runtimes like runc use Linux namespaces to make a process believe it is alone on a machine (it has its own PID 1, its own network interfaces, its own filesystem root), and cgroups to limit how much CPU and memory it can consume. But both the container process and every other process on the host share the same Linux kernel.
This has a critical security implication: every system call a container process makes — open(), read(), socket(), clone() — goes directly to the single kernel running on the host. The kernel is the shared attack surface.
If a container process can exploit a kernel vulnerability (a buffer overflow in a syscall handler, a race condition in a namespace implementation), it can potentially escape the container entirely and gain root access to the host. Real-world examples include CVE-2019-5736 (runc container escape) and CVE-2022-0185 (Linux kernel heap overflow exploitable from within a container).
For most workloads — running your own trusted application code — this risk is acceptable and well-managed through careful kernel patching and security profiles (seccomp, AppArmor). But for multi-tenant workloads — running arbitrary, untrusted code from different customers on the same physical server — sharing a kernel is often an unacceptable risk.