Shulou(Shulou.com)06/02 Report--

How to isolate users in the docker container? In view of this problem, this article introduces the corresponding analysis and answers in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible way.

User Mapping of User namespace

Before configuring docker daemon to enable user namespace, I need to understand some concepts about subordinate users / groups and remapping. The mapping of dependent users and groups is controlled by two profiles, / etc/subuid and / etc/subgid. Take a look at their default content: before configuring docker daemon to enable user namespace, I need to understand some concepts about subordinate users / groups and remapping:

For subuid, this line of record means:

The user nick, which has 65536 subordinate users in the current user namespace with a user ID of 100000-165535, is mapped to a user with an ID of 0-65535 in a child user namespace. The meaning of subgid is the same as subuid.

For example, user nick is only a user with ordinary permissions on the host. We can assign one of his slave ID, 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 permission, it is only in the user namespace where the container resides. Once in the host, you will at most have the permission of nick user.

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

Nick:100000:65536dockeruser:165536:65536

And assign it to docker daemon:

{"userns-remap": "dockeruser"}

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

Or keep it simple, let docker do these tedious things for us, and directly specify the userns-rempa parameter of docker daemon as "default":

{"userns-remap": "default"}

At this point, docker will automatically complete the other configuration.

Configure docker daemon to enable user isolation

Here the author takes a simple way to let docker create a default user for user namespace. We need to create the / etc/docker/daemon.json file first:

$sudo touch / etc/docker/daemon.json

Then edit it as follows (if the file already exists, just add the following configuration item), 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 to see if items related to the new user dockremap have been added to the / etc/subuid and / etc/subgid files:

Next we find that we have created a new directory under the / var/lib/docker directory: 165536.165536, to view the permissions of this directory:

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

It is basically the same as the content in the / var/lib/docker directory, indicating that all the contents related to the files will be placed in the new 165536.165536 directory after user isolation is enabled.

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

Uid in Host and uid in Container

After docker daemon enables user isolation, let's take a look at the changes between 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 user dockremap and does not have any special permissions in the host. However, the user in the container is root, and the result looks perfect:

The newly created container creates a user namespace

Before docker daemon enables user isolation, the newly created container process is in the same user namespace as the process on the host. That is, docker does not create a new user namespace for the container:

The container process sleep in the above figure is in the same user namespace as the process on the host (there is no scenario where the user isolation feature is enabled).

After docker daemon enables user isolation, let's look at the user namespace of the process in the container:

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 the god and has the supreme power!

Access files in a data volume

We can prove what permissions the root user has in the container by accessing the files in the data volume. Create four files that belong to users root, 165536, and nick. Rootfile only root user can read and write, user nick has read and write permission of nickfile, uid 165536 has read and write permission of file 165536file, any user can read and write testfile file:

Let's 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, indicating that this user has only very limited permissions in the host.

Disable user namespace in the container

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

Docker container createdocker container rundocker container exec

For example, execute the following command:

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

View process information:

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

Known problem

User namespace is a relatively advanced feature, and the current docker support for it is not perfect. Here are a few known issues that are not compatible with existing features:

PID or NET namespace of the shared host (--pid=host or-- network=host)

External storage, data volume drivers may not be compatible, do not support user namespace

Use-- privileged instead of specifying-- userns=host

Summary

Docker supports user namespace, and it is very easy to configure. After opening user namespace, we have enjoyed the improvement of security, but at the same time, other individual features will have problems because of various restrictions. At this point, we need to make a choice, say goodbye to one-size-fits-all decisions, and let the right features appear in the right scenarios.

This is the answer to the question about how to isolate users in the docker container. I hope the above content can be of some help to you. If you still have a lot of questions to solve, you can follow the industry information channel for more related knowledge.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.