Namespaces

The other part of the container puzzle is kernel namespaces. They operate in a manner that is somewhat similar to our use of the chroot syscall in that a container engine instructs the kernel to only allow the process a particular view of the system's resources.

Instead of just limiting access to the filesystem kernel, namespaces limit access to a number of different resources.

Each process can be assigned to a namespace and can then only see the resources connected to that namespace. The kinds of resources that can be namespaced are as follows:

• Mount: Mount namespaces control access to the filesystem.
• Users: Each namespace has its own set of user IDs. User ID namespaces are nested, and thus a user in a higher-level namespace can be mapped to another in a lower level. This is what allows a container to run processes as root, without giving that process full permission to the root system.
• PID: The process ID namespace, like the users namespace, is nested. This is why the host can see the processes running inside of the containers when inspecting the process list on a system that is running containers. However, inside of the namespace the numbers are different; this means that the first process created inside a PID namespace, can be assigned PID 1, and can inherit zombie processes if required.
• Network: A network namespace contains one or more network interfaces. The namespace has its own private network resources, such as addresses, the routing table, and firewall.