1.3.1.5 Isolation Boundary Contrast

Isolation boundary contrast examines precisely where the line of isolation sits for a Docker container compared to a virtual machine, clarifying what each technology actually protects against and what it does not.

The Virtual Machine's Isolation Boundary

A virtual machine's isolation boundary sits at the hardware-virtualization layer: each VM has its own kernel, its own view of memory, and is managed by a hypervisor that mediates all access to physical hardware. A process inside one VM has no direct path to interact with a process inside another VM, because there is no shared kernel between them at all.

virsh list --all

The Container's Isolation Boundary

A container's isolation boundary sits inside a single shared kernel: namespaces give each container its own view of processes, network interfaces, and mounts, and cgroups limit its resource consumption, but the kernel enforcing all of this is the same kernel instance for every container on the host.

docker run --rm myapp ps aux

A process inside this container cannot see processes in other containers, because the PID namespace isolates that view — but the isolation is enforced by kernel-level bookkeeping, not by a separate kernel.

What Each Boundary Protects Against

The VM boundary protects against an entire class of kernel-level attacks: a compromised guest kernel cannot directly act on the host kernel or on other VMs' kernels. The container boundary protects against accidental interference and resource contention between processes, and against many forms of privilege escalation, but a sufficiently severe kernel vulnerability could, in principle, be used to affect other containers sharing that kernel.

Strengthening the Container Boundary

Various mechanisms exist to narrow the gap between the two: running containers as non-root users, applying seccomp profiles to limit available system calls, and using read-only filesystems all reduce what a compromised container could do even if a kernel-level escape were possible.

docker run --user 1000:1000 --read-only --security-opt=no-new-privileges myapp:1.0

Choosing Based on the Isolation Boundary Needed

Workloads that must isolate mutually untrusted tenants from each other at the strongest possible level typically still favor virtual machines, or a combination of both (containers running inside per-tenant VMs), while workloads operating within a single trust boundary commonly accept the container-level isolation boundary in exchange for its efficiency.