Namespaces: the kernel view a container is allowed to see

Eight views, one process

Why does this matter to you? Because when something breaks — a zombie leak, a missing network interface, a root process that can’t mount — the namespace type tells you exactly which boundary failed and where to look. Knowing all eight is knowing the container’s full surface area.

A namespace wraps a single global kernel resource so that processes inside it see their own instance of it. There are 8 namespace types on a modern kernel, and a container is simply a process placed into a fresh set of them:

• PID — process IDs; the first process becomes PID 1.
• mount (mnt) — the filesystem tree; this is what makes the container’s / its own root.
• network (net) — interfaces, routing tables, the loopback, iptables.
• UTS — hostname and domainname (so hostname inside differs from the host).
• IPC — System V IPC and POSIX message queues.
• user — UID/GID maps; lets root-in-container (UID 0) map to an unprivileged host UID.
• cgroup — what view of the cgroup tree the process sees.
• time — boot/monotonic clock offsets (added in kernel 5.6).

Together these eight types cover the complete kernel view a process can ask about: who am I, what files exist, what’s on the network, what’s my hostname, who can I talk to via IPC, what cgroup tree do I see, and what does the clock say. Drop any one of them and the container leaks into the host’s global view for that resource — which is exactly the class of bug that shows up as “it worked locally but not in the pod.”

The critical mental shift: the container process is the same kind of object as any host process. ps on the host shows it directly, scheduled by the same scheduler, in the same kernel. There is no guest kernel, no hypervisor trap. Isolation is just: when this process asks “what PIDs exist?”, the kernel answers from its PID namespace, not the global one.

// Roughly what a runtime does to create a container's first process.
// CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET | CLONE_NEWUTS |
// CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWCGROUP  — one flag per namespace.
int flags = CLONE_NEWPID | CLONE_NEWNS | CLONE_NEWNET |
            CLONE_NEWUTS | CLONE_NEWIPC | CLONE_NEWUSER | CLONE_NEWCGROUP;
pid_t pid = clone(child_fn, stack_top, flags | SIGCHLD, arg);
// child_fn now runs as PID 1 in a brand-new namespace set.

runc — the OCI runtime Docker and containerd call — reads the linux.namespaces array from the container’s config.json and unshare(2)s / clone(2)s exactly those. Namespaces are orthogonal: you can take a network namespace but share the host’s PID namespace, which is exactly what docker run --pid=host does, and what makes a debugging sidecar able to ps the target container.

Mount and network: the visible isolation

Two namespaces do most of the work you see. The mount namespace gives the container its own filesystem tree: the runtime pivot_roots into the unpacked image, so the container’s / is the image’s root, and host paths simply do not exist in its view unless explicitly bind-mounted. The network namespace gives it its own loopback, its own interfaces, its own routing and firewall tables — which is why a fresh container has only lo until the runtime moves one end of a veth pair into it and wires the other end to a bridge on the host. A namespace persists as long as a process is in it or a file descriptor or bind-mount pins it; this is how ip netns and docker exec re-enter an existing container’s namespaces via setns(2) rather than creating new ones.

The user namespace is the security keystone and the one most often left off: with userns-remap, UID 0 inside the container maps to an unprivileged host UID (say 100000), so a container “root” who escapes a mount has the host privileges of nobody. Without it, root-in-container is root-on-host the instant any other barrier (a bad bind-mount, a capability you forgot to drop) gives way.