How containers really work: namespaces, cgroups and images

Imagine a big school kitchen. Every child brings their own lunchbox. The kitchen — the cooker, the sink, the electricity — is shared by everyone. But each child can only see and eat what is in their own box. They cannot reach into someone else's box, and they cannot make a mess that spoils anyone else's lunch.

A container is like one of those lunchboxes. The shared kitchen is the Linux kernel running on the server. Each container is a program that thinks it is alone on the whole machine — it has its own view of files, its own network address, and its own list of processes. But underneath, it is just borrowing the school's kitchen, the same as everyone else.

A virtual machine, by contrast, is like building an entirely new kitchen inside the first one — walls, cooker, sink, and all. It is completely separate, but it takes up a lot more room and takes longer to set up.

A container is a Linux process (or group of processes) that runs with an isolated view of the system — its own filesystem, its own network interfaces, its own process tree — while sharing the host kernel directly. There is no second operating system; there is no hypervisor translating hardware instructions.

A virtual machine does the opposite. A hypervisor (KVM, VMware, Hyper-V) virtualises the hardware itself. Each VM boots its own kernel, its own init system, its own userland. This makes VMs heavier and slower to start, but also more strongly isolated: a bug in one VM's kernel cannot directly affect another.

Linux achieves container isolation with two main kernel features:

• Namespaces — give each container its own isolated view of kernel resources (processes, networking, filesystems, hostname, and more).
• cgroups (control groups) — limit how much CPU, memory, I/O, and other resources a container may consume.
• Union filesystems — let container images be assembled from read-only layers, with a thin writable layer on top, keeping images small and shareable.

When you run docker run nginx, Docker (or Podman) asks the kernel to create a new set of namespaces, applies cgroup limits, mounts the image layers, and then executes the nginx binary inside that environment. Nginx sees itself as PID 1 on a fresh machine. The host kernel sees it as just another process.

Let us compare the two stacks side by side, then drill into each primitive.

For comparison, a VM inserts a Guest OS Kernel, a Hypervisor, and often a firmware/BIOS layer between your app and the hardware. A container skips all of that.

Namespaces are the core isolation mechanism. The kernel currently ships seven namespaces relevant to containers:

cgroups v2 (the unified hierarchy, default on modern distros since Linux 5.2) organises processes into a tree and enforces resource budgets. A typical container runtime sets limits such as:

Images and OverlayFS — a container image is a stack of read-only layers, each one a tar archive of filesystem changes. OverlayFS merges them into a single unified directory tree with one writable upper layer on top (the container layer). Writes trigger copy-on-write: the kernel copies the file from a lower read-only layer into the upper layer before modifying it. Delete and re-create a container and the upper layer vanishes; the shared lower layers remain untouched, saving both disk space and pull time.

The runtime stack follows the OCI specifications. When you run a container:

• Docker Engine / Podman — the user-facing API and daemon.
• containerd — an OCI-compliant container runtime daemon; manages image pulls, snapshots, and lifecycle.
• runc — the low-level runtime that actually calls clone(), sets up cgroups, mounts OverlayFS, and exec()s the entry-point. It is the reference implementation of the OCI Runtime Specification.
• OCI Image Spec — defines how image layers and manifests are stored and distributed.
• OCI Runtime Spec — defines the config.json bundle that runc consumes.

Container networking with veth pairs — when containerd creates a network namespace for a container, the networking plugin (e.g. CNI bridge plugin) creates a virtual Ethernet pair: two linked virtual NICs. One end (eth0) lives inside the container's net namespace; the other end (veth0abc) lives in the host namespace and is attached to a Linux bridge (docker0 by default). Traffic between containers flows across that bridge; traffic to the outside world is NAT'd via iptables MASQUERADE rules. ip link and ip netns on the host reveal the full topology.

Kubernetes pods re-use the same primitives. A pod is a group of containers that share a single net, uts, and ipc namespace — but each has its own mnt namespace. This is why containers in the same pod can talk on localhost and see each other's processes via IPC, yet have independent filesystems. A pause container (the 'infra' container) holds the shared namespaces open for the lifetime of the pod; the application containers join them.

cgroups v1 vs v2 — cgroups v1 allowed controllers to be mounted independently, leading to inconsistency (a process could be in different hierarchies for cpu vs memory). cgroups v2 uses a single unified hierarchy at /sys/fs/cgroup. Kubernetes added full cgroups v2 support in 1.25. When specifying --cpus or memory limits, remember these are enforced on the host scheduler, not a virtual CPU count — a container limited to 0.5 CPUs on a 32-core host gets 50 ms of every 100 ms period, shared across all its threads.

Image layer deduplication — because OverlayFS layers are content-addressed and shared on disk, ten containers based on the same ubuntu:24.04 base image share one copy of those layers. This matters at scale: a node running 50 nginx containers may hold only one copy of the nginx image layers, with 50 thin writable upper-dirs. However, large writes inside a container (e.g. database files) should use a volume mounted directly, not the overlay upper layer, which has I/O overhead from copy-on-write.

Linux capabilities — traditionally Unix privileges were binary: root (UID 0) could do everything; everyone else was restricted. Since Linux 2.2, root's power is split into roughly 40 discrete capabilities (CAP_NET_ADMIN, CAP_SYS_PTRACE, CAP_MKNOD, etc.). Container runtimes drop the vast majority by default. Docker's default set retains roughly 14 capabilities — enough to run most web services but not enough to load kernel modules or rebind arbitrary ports below 1024 on the host.

seccomp filters add a second layer: a Berkeley Packet Filter (BPF) programme attached to the process that inspects every syscall number and either allows or kills it. Docker ships a default seccomp profile that blocks around 44 syscalls (including ptrace, keyctl, mount, reboot, and several esoteric ones). The profile is a JSON file you can audit at /etc/docker/seccomp-default.json or the Moby repository.

no_new_privs — runc sets the PR_SET_NO_NEW_PRIVS prctl flag on the container process, preventing it (and any child) from gaining new privileges via setuid binaries or filesystem capabilities. This means even if an attacker escapes to a setuid binary inside the container, it will not elevate them.

Rootless containers and user namespaces — this is where it gets elegant. A user namespace remaps UIDs. Inside the namespace, UID 0 is mapped to, say, host UID 100000. From the kernel's perspective, the process is unprivileged. The container process thinks it is root and can do things that require UID 0 inside its namespaces (mount certain filesystems, bind to ports below 1024 inside the net namespace, etc.) but the host kernel enforces the mapping — it can never affect anything outside the namespace with host-root power.

AppArmor and SELinux provide a further Mandatory Access Control (MAC) layer orthogonal to namespaces and capabilities. Docker generates an AppArmor profile (docker-default) that, among other things, prevents reading /proc/sysrq-trigger and writing to /proc/sys. Kubernetes uses SELinux labels (svirt_lxc_net_t) on Red Hat-family nodes. These are defence-in-depth: they limit damage even if namespace isolation is bypassed.

Image supply-chain security — an image is only as trustworthy as its layers. Each layer is a tar pulled by content-addressed digest (SHA-256), so layer tampering is detectable. However, the tag-to-digest mapping is mutable. Use image digests (image@sha256:...) in production manifests rather than tags. Tools like Cosign (Sigstore) provide cryptographic image signing; Trivy or Grype scan layers for known CVEs before they reach production.

Common escape vectors (for threat-modelling) — the vast majority of historical container escapes have involved: mounted Docker socket (/var/run/docker.sock) giving full daemon control; --privileged combined with mounting /dev or /proc; kernel vulnerabilities in syscall paths reachable despite seccomp (e.g. runc CVE-2019-5736 via /proc/self/exe); and writable host path mounts. Mitigations: drop the socket, do not use --privileged, keep the kernel patched, and run rootless.