Manage containers in namespaces by using nsenter (2024)

With containers becoming the de facto application deployment standard, we all must understand how to guarantee security, isolation, and resource restrictions. Linux namespaces play an essential role in isolating the resources allocated to containers. This article shows how to use nsenter to demystify what is happening inside the world of namespaces, be it in a containerized or traditional environment.

Namespaces: What exactly are they?

The kernel allocates and restricts the resources for individual processes running on the Linux operating system. The namespaces within the kernel partition these resources. Namespaces allocate the resources to a process such that the process only sees those specific resources. Namespaces provide isolation among the process, managing what system resources they can see. This technology is widely-used in container runtimes to provide a layer of isolation among containers that run on the same host.

Overview of the different namespaces

Linux namespaces existed as early as kernel version 2.4. Continued kernel development has added more namespaces. As of version 5.6, there are eight different namespaces.

For more details on these individual namespaces, please refer to man 7 namespaces. The OpenvSwitch (OvS) Software Defined Networking (SDN) plugin used in OpenStack and OpenShift uses namespaces to provide the true multi-tenancy on the networking layer.

[ Getting started with containers? Check out this free course. Deploying containerized applications: A technical overview.]

Linux containers and namespaces

To demonstrate the namespaces managing a container, I'll use Podman to create a container from the UBI8:8.2 image from Red Hat Container Catalog. The container resides on a Red Hat Enterprise Linux (RHEL) 8.2 host. For the purpose of this article, the procps-ng package is installed inside the container, which provides top and ps commands.

[root@workshop ~]# podman run --name namespace-demo -it registry.access.redhat.com/ubi8/ubi /bin/bash

In another terminal, use the runc command to determine the process id associated with the new container.

[root@workshop ~]# runc listID PID STATUS BUNDLE CREATED OWNER92585ccfd2d20c4bc7f03863d9b0a999eea18c91fb76f6333ef21171138beb83 7172 running /var/lib/containers/storage/overlay-containers/92585ccfd2d20c4bc7f03863d9b0a999eea18c91fb76f6333ef21171138beb83/userdata 2020-06-24T14:56:37.895046979Z root

The process id is 7172.

Use the lsns command to list the namespaces associated with a given process.

[root@workshop ~]# lsns -p 7172 NS TYPE NPROCS PID USER COMMAND4026531835 cgroup 137 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 164026531837 user 137 1 root /usr/lib/systemd/systemd --switched-root --system --deserialize 164026532438 net 1 7172 root /bin/bash4026532516 mnt 1 7172 root /bin/bash4026532517 uts 1 7172 root /bin/bash4026532518 ipc 1 7172 root /bin/bash4026532519 pid 1 7172 root /bin/bash

Inspect the namespaces with nsenter

The nsenter command expands to namespace enter. It accepts different options to only enter the specified namespace.

Let's enter the network namespace to check the IP address and route table.

[root@workshop ~]# nsenter -t 7172 -n ip a s1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever3: eth0@if9: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default link/ether ea:95:99:52:13:56 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.88.0.6/16 brd 10.88.255.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::e895:99ff:fe52:1356/64 scope link valid_lft forever preferred_lft forever

Here, -t is the target process id, and -n refers to the network namespace.

[root@workshop ~]# nsenter -t 7172 -n ip routedefault via 10.88.0.1 dev eth010.88.0.0/16 dev eth0 proto kernel scope link src 10.88.0.6

Next, I enter the process namespace to check the process details.

[root@workshop ~]# nsenter -t 7172 -p -r ps -efUID PID PPID C STIME TTY TIME CMDroot 1 0 0 14:56 pts/0 00:00:00 /bin/bashroot 135 0 0 16:55 ? 00:00:00 ps -ef

The -r option sets the root directory to the top-level directory within the namespace so that the commands run in the context of the namespace.

[root@workshop ~]# nsenter -t 7172 -p -r top

The bash command, which executes during podman run, is the first process inside the namespace.

Enter the UTC namespace to check the hostname.

[root@workshop ~]# nsenter -t 7172 -u hostname92585ccfd2d2

Modify the hostname within the namespace and verify the new name.

[root@workshop ~]# nsenter -t 7172 -u hostname namespace.enable.sysadmin[root@workshop ~]# nsenter -t 7172 -u hostnamenamespace.enable.sysadmin

Finally, enter all namespaces by using the -a option.

[root@workshop ~]# nsenter -t 7172 -a[root@namespace /]# df -hFilesystem Size Used Avail Use% Mounted onoverlay 7.9G 6.3G 1.6G 80% /tmpfs 64M 0 64M 0% /devtmpfs 1.9G 1.4M 1.9G 1% /etc/hostsshm 63M 0 63M 0% /dev/shmtmpfs 1.9G 0 1.9G 0% /sys/fs/cgrouptmpfs 1.9G 0 1.9G 0% /proc/acpitmpfs 1.9G 0 1.9G 0% /proc/scsitmpfs 1.9G 0 1.9G 0% /sys/firmwaretmpfs 1.9G 0 1.9G 0% /sys/fs/selinux

Summary

Linux containers help with rapid application delivery and the use of DevOps practices. It is essential to make sure that those applications are secure, isolated, and resource-restricted. The nsenter tool helps you understand the low-level details of a container. It also helps with troubleshooting issues with container orchestration and deployment.

[ Start using containers for free: Try OpenShift Container Platform 4. ]

Topics: Containers Podman