How to isolate users in docker containers

In the previous article "Understanding UID and GID in Docker Containers", the author introduced the relationship between users in Docker containers and users on the host machine, and concluded that Docker does not isolate host users and users in containers by default. If you already know Linux's user namespace technology (see "Linux Namespace: User"), then you will naturally ask: Why doesn't Docker use Linux user namespace to achieve user isolation? In fact, Docker has already implemented related functions, but they are not enabled by default. In this article, I will describe how to configure Docker to isolate users in containers.
Note: The demonstration environment of this article is Ubuntu 16.04.

Understanding Linux user namespace

The Linux user namespace provides security-related isolation (including uid and gid) for running processes, restricting their access to system resources without the processes being aware of these restrictions. For an introduction to Linux User Namespace, please refer to my article "Linux Namespace: User".

For containers, the best way to prevent privilege-escalation attacks is to run container applications with normal user privileges.
However, some applications must run as the root user in the container, which is the best scenario for us to use user namespace. We use the user namespace technology to map an ordinary user (a user with only ordinary permissions) in the host to the root user in the container. In the container, the user considers himself to be the root in his own user namespace and has all the permissions of the root, but he has only very limited access rights (ordinary user) to the resources on the host.

User namespace user mapping

Before configuring Docker daemon to enable user namespace, I need to understand some concepts about subordinate users/groups and remapping. The mapping of subordinate users and groups is controlled by two configuration files, /etc/subuid and /etc/subgid. Take a look at their default contents: Before configuring docker daemon to enable user namespace, I need to understand some concepts about subordinate users/groups and mapping (remapping):

For subuid, the meaning of this line is:

User nick has 65536 subordinate users in the current user namespace, with user IDs ranging from 100000 to 165535. In a child user namespace, these subordinate users are mapped to users with IDs ranging from 0 to 65535. subgid has the same meaning as subuid.

For example, user nick is just a user with ordinary permissions on the host machine. We can assign one of its subordinate IDs (such as 100000) to the user namespace to which the container belongs, and map ID 100000 to uid 0 in that user namespace. At this point, even if the process in the container has root privileges, it is only in the user namespace where the container is located. Once it is in the host machine, you will at most have the privileges of a nick user.

When Docker's support for user namespace is enabled (Docker's userns-remap function), we can specify different users to be mapped to the container. For example, we create a user dockeruser and manually set its subuid and subgid:

nick:100000:65536
dockeruser:165536:65536

And assign it to the docker daemon:

{
 "userns-remap": "dockeruser"
}

Please note the subuid setting information. The subordinate ID we set for dockeruser and nick user do not overlap. In fact, the subordinate ID settings of any user cannot overlap.

Or we can keep it simple and let Docker do all the hard work for us, just specify the userns-rempa parameter of Docker daemon as "default":

{
 "userns-remap": "default"
}

At this point, Docker will automatically complete other configurations.

Configure Docker daemon to enable user isolation

Here I take a simple approach and let Docker create a default user for the user namespace. We need to create the /etc/docker/daemon.json file first:

$ sudo touch /etc/docker/daemon.json

Then edit its content as follows (if the file already exists, just add the following configuration items), and restart the Docker service:

{
 "userns-remap": "default"
}

$ sudo systemctl restart docker.service

Let's verify a few points about user isolation.

First verify that docker created a user named dockremap:

Then check whether the new user's dockremap related items have been added to the /etc/subuid and /etc/subgid files:

Next, we found that a new directory was created under the /var/lib/docker directory: 165536.165536. Check the permissions of the directory:

165536 is a uid mapped by user dockremap. View the contents of the 165536.165536 directory:

It is basically consistent with the content in the /var/lib/docker directory, indicating that after user isolation is enabled, file-related content will be placed in the newly created 165536.165536 directory.

Through the above checks, we can confirm that the docker daemon has enabled the user isolation function.

UID in the host and UID in the container

After enabling user isolation in Docker daemon, let's take a look at the changes in the uid in the host and the uid in the container.

$ docker run -d --name sleepme ubuntu sleep infinity 

uid 165536 is a subordinate ID of the user dockremap and has no special permissions on the host machine. However, the user in the container is root, so the result looks perfect:

The newly created container will create a user namespace

Before the Docker daemon enables user isolation, the newly created container process and the process on the host are in the same user namespace. That is to say, Docker does not create a new user namespace for the container:

In the figure above, the container process sleep and the process on the host are in the same user namespace (the user isolation function is not enabled).

After enabling user isolation in the docker daemon, let's view the user namespace of the process in the container:

The 4404 in the figure above is the PID of the sleep process in the container we just started. As you can see, Docker creates a new user namespace for the container. In this user namespace, the user root in the container is a god and has supreme power!

Access files in the data volume

We can access the files in the data volume to prove what permissions the root user in the container has. Create four files, belonging to users root, 165536, and nick respectively. Only the root user can read and write rootfile. User nick has read and write permissions for nickfile. UID 165536 has read and write permissions for file 165536file. Any user can read and write testfile:

Next, mount these files into the container as data volumes and check the permissions to access them from the container:

$ docker run -it --name test -w=/testv -v $(pwd)/testv:/testv ubuntu 

The root user in the container can only access 165536file and testfile, which means that this user has very limited permissions in the host machine.

Disable user namespace in container

Once the "userns-remap" parameter is set for the docker daemon, all containers will have user isolation enabled by default (a new user namespace is created by default). In some cases, we may need to return to the scenario where user isolation is not enabled. In this case, we can disable user isolation for a single container by using the --userns=host parameter. The --userns=host parameter is mainly used for the following three commands:

docker container create
docker container run
docker container exec

For example, execute the following command:

$ docker run -d --userns=host --name sleepme ubuntu sleep infinity

View process information:

The effective user of the process becomes root again, and no new user namespace is created for the process:

Known Issues

User namespace is a relatively advanced feature. Currently, Docker's support for it is not perfect. The following are several known incompatibilities with existing features:

• Share the host's PID or NET namespace (--pid=host or --network=host)
• External storage and data volume drivers may not be compatible and may not support user namespace.
• Using --privileged without specifying --userns=host

Summarize

Docker supports user namespace, and the configuration method is also very simple. After enabling user namespace, we enjoy improved security, but at the same time, other individual functions may have problems due to various restrictions. At this time, we need to make a choice, say goodbye to one-size-fits-all decisions, and make the right functions appear in the right scenarios.

refer to:

Understanding how uid and gid work in Docker containers
Introduction to User Namespaces in Docker Engine
Isolate containers with a user namespace

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.