Namespaces: Each Container's Private View

In one line

Linux namespaces give a process its own view of process IDs, network interfaces, mount points, hostname, IPC, users, and cgroups; a container is a process in a set of new namespaces.

0/4 · 0%

Think of it like this

A hotel room. Guests share the same building (the kernel), but each room has its own door number, phone line, and minibar. From inside the room, you can't see the other guests. Namespaces are the walls.

Key ideas

01
The namespace types: PID (the container sees its own processes, and its main process is PID 1), NET (own interfaces, IPs, routes; the Networking course, Topic 6.2, builds one by hand), MNT (own filesystem mounts), UTS (own hostname), IPC (own shared memory), USER (map root inside to an unprivileged user outside), and CGROUP (own view of its cgroup tree).
02
PID 1 is special: it receives signals like SIGTERM on docker stop and must forward them and reap zombie child processes. That's why apps started through a shell script sometimes ignore shutdown signals, and why --init (tini) exists (Docker course, Topic 2.5).
03
From the host, containers are just processes: ps shows them, and /proc/<pid>/ns/ shows which namespaces they're in. nsenter can enter a container's namespaces, which is how debugging tools attach to minimal images that have no shell.
04
Namespaces are isolation, not a security boundary as strong as a VM: all containers share the host kernel. That's why hardening (non-root, dropped capabilities, seccomp) matters (DevSecOps course, Lab 2.1).

Code & diagrams

namespaces.shbash

docker run -d --name demo nginx:alpine
PID=$(docker inspect -f '{{.State.Pid}}' demo)     # the container's PID 1, as seen from the host
sudo ls -l /proc/$PID/ns                           # its namespaces
sudo nsenter -t $PID -n ip addr                    # run the HOST's ip binary inside its network namespace
sudo unshare --pid --fork --mount-proc sh -c 'ps aux'   # a new PID namespace: you are PID 1
docker rm -f demo

Explain it without notes

Why can you see a container's processes from the host, but not the host's processes from inside the container?

Practice

A distroless container has no shell. How can you run ip addr or ss against its network namespace?

Trade-offs

↔
Namespaces make containers start in milliseconds with almost no overhead, but the shared kernel means weaker isolation than VMs; sandboxed runtimes (gVisor, Kata Containers, Firecracker) add a VM-like boundary at some cost.

Done when you can

I can list the namespace types and what each isolates.
I know why PID 1 must handle signals and reap children.
I can inspect and enter a container's namespaces from the host.