Linux namespaces and containers explained for working administrators

Containers have reshaped how infrastructure is deployed, from startup prototypes in Brisbane co-working spaces to the data centres that host the ASX trading platforms. At the heart of every container sits a Linux kernel feature that most administrators interact with daily but rarely study in isolation: namespaces.

Namespaces provide the isolation that makes containers feel like lightweight virtual machines. They wrap processes in a thin membrane so that each container believes it owns the system, while the host kernel keeps tight control over what is shared and what remains private.

The technology is not new, but its mainstream adoption followed the release of Docker in 2013. Since then, Australian organisations have moved quickly to adopt container orchestration, partly driven by local data sovereignty requirements and the need to keep workloads close to the Sydney and Melbourne cloud regions.

This walkthrough explores the major namespace types, shows how they interact with control groups, and demonstrates practical commands you can run on RHEL, CentOS Stream, or Fedora to inspect what your containers are really doing under the hood.

The kernel primitives behind container isolation

A namespace is a kernel object that partitions a global system resource. When a process is created with a new namespace, it receives a private view of that resource. Multiple namespaces of the same type can exist simultaneously, and a process belongs to exactly one instance of each type.

The kernel supports several namespace flavours. The most relevant for containers are mount, UTS, IPC, PID, network, and user namespaces. Each handles a specific resource category, from process identifiers to network interfaces and hostname settings.

To list which namespaces a process belongs to, read the symbolic links under /proc/<pid>/ns/. For example, /proc/1/ns/pid reveals the PID namespace of the init process. A quick command like ls -l /proc/1/ns/ shows the inode for each namespace, and comparing those inodes across processes reveals which ones share isolation boundaries.

PID namespaces and process visibility

PID namespaces give a container its own numbering space for processes. The first process inside a new PID namespace receives PID 1 and behaves like init, gaining special signal-handling responsibilities that mirror the host's init system.

This is why killing PID 1 inside a container is handled differently from killing an arbitrary process. The container runtime signals the namespace leader, which often triggers graceful shutdown routines defined in the container image.

From a debugging perspective, you can enter a container's PID namespace using nsenter. Running nsenter -t <pid> -m -p -n /bin/bash drops you into the mount, PID, and network namespaces of an existing process, which is invaluable when investigating a misbehaving service without starting a new shell.

In Australian financial environments regulated by APRA, the ability to audit and inspect process activity inside isolated environments is often a requirement. Understanding PID namespaces helps satisfy CPS 234 obligations around information security testing. The SFCDI community portal also documents practical examples of namespace-based sandboxing for training environments, which is useful when setting up isolated lab systems for staff development.

Network namespaces and virtual interfaces

Network namespaces provide independent network stacks, each with its own interfaces, routing tables, and firewall rules. This is what allows two containers on the same host to bind to port 80 without conflict, and it is the basis for the virtual ethernet pairs that connect containers to bridges.

When a container starts, the runtime typically creates a veth pair, with one end placed inside the container's network namespace and the other attached to a bridge on the host. From the host, the container appears as just another interface on the bridge, and standard tools like iptables or nftables can shape traffic.

For administrators managing web services behind Nginx, this separation is particularly useful. You can run several Nginx instances on a single host, each in its own network namespace, and apply distinct upstream configurations without port collisions.

Mount namespaces and filesystem views

Mount namespaces give containers their own filesystem hierarchy. A process inside a mount namespace only sees the mounts that have been declared within that namespace, which is why changes to the filesystem in one container do not affect siblings or the host.

This isolation is what enables bind mounts, overlay filesystems, and the read-only layers that characterise container images. Tools like mount and umount operate against the current namespace, so you can safely manipulate mounts inside a container without touching the host.

For testing configuration changes, unshare --mount /bin/bash opens a shell in a new mount namespace where you can experiment with mount points in isolation. When you exit, the namespace is destroyed and the host filesystem remains untouched, which is ideal for safe experimentation in production-adjacent environments.

Practical commands for exploring namespaces

Beyond unshare and nsenter, several utilities make namespace inspection routine. The lsns command, available from the util-linux package on RHEL-based distributions, lists all namespaces along with their types, PIDs, and owners.

Systemd units can be configured with PrivateNetwork, MountFlags, or PrivateTmp to drop services into restricted namespaces without writing custom scripts. This approach is favoured by distribution maintainers and aligns with the hardening guidance published by the Australian Cyber Security Centre.

For more background on how this fits into broader Linux administration practices, the Linuxtpoint site outlines the tutorial library and learning paths available.

Understanding namespaces transforms the way you think about containers. Rather than opaque black boxes, containers become predictable compositions of kernel features, each of which you can inspect, restrict, or replicate. The most valuable habit is to spend time with the /proc filesystem, because every container running on your system leaves its fingerprint there, and learning to read those fingerprints is what separates an experienced administrator from someone who simply follows runbooks.