Docker Isn't Magic: The 5 Linux Kernel Features Behind It

Containers are not mini virtual machines. A VM virtualizes hardware and runs its own kernel; a container shares the host's kernel and uses a handful of kernel features to create the illusion of separation.

Understanding those features makes Docker behavior - and Docker failures - much easier to reason about. Here are the five kernel mechanisms that do the actual work.

1. Namespaces: what a process can see

Namespaces partition global system resources so that each process group sees its own view. The important ones:

• pid - the container sees its own process tree, starting at PID 1.
• net - the container gets its own network stack, interfaces, and routing table.
• mnt - the container sees only the mounts given to it, not the host's filesystem.
• ipc and user - isolate inter-process communication and user/group IDs.

Namespaces are isolation, not a security boundary. A process inside a container still makes syscalls to the same host kernel.

2. Cgroups: how much a container can use

Namespaces control visibility; cgroups control consumption. They account for and limit CPU, memory, block I/O, and more:

docker run --cpus=2 --memory=1g myapp

That command translates into cgroup limits. Without them, one runaway process can starve every other container and the host itself.

3. Capabilities: what root means

Traditional root is all-or-nothing. Linux capabilities split root into distinct units, so you can drop the ones a container does not need:

docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE myapp

The container can bind to a low port but cannot load kernel modules or change the system clock.

4. Seccomp: filtering syscalls

Seccomp blocks specific system calls entirely. Docker applies a default profile that denies hundreds of dangerous or unnecessary calls. A process that attempts a blocked syscall is killed with SIGSYS.

For sensitive workloads you can ship a custom profile that allows only what the application actually uses.

5. veth + bridge + iptables: container networking

When a container starts, the runtime creates a virtual Ethernet pair. One end lives in the container's network namespace; the other attaches to a bridge on the host (docker0). iptables rules then handle NAT for outbound traffic and DNAT for port mappings:

docker run -p 8080:80 myapp

That -p flag programs a DNAT rule that redirects host port 8080 into the container's port 80.

How docker run wires it together

• Create mount/pid/net namespaces for the container.
• Create the veth pair and program bridge/NAT rules.
• Apply cgroup limits.
• Apply the default seccomp profile.
• Drop unnecessary capabilities.
• Exec the entrypoint.

What this does not cover

This is the mechanics of a single container on one host. It does not cover the container runtime's image layering, orchestration schedulers, or the many ways a misconfigured container can still escape its isolation. Those are separate topics - and the reason kernel-level defaults alone are not enough.

Adapted from the deeper dive on hSECURITIES.