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

This article mainly introduces the relevant knowledge of "how to isolate users in docker container". Xiaobian shows you the operation process through actual cases. The operation method is simple, fast and practical. I hope this article "how to isolate users in docker container" can help you solve the problem.

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 these processes being aware of these restrictions. For an introduction to the Linux user namespace, please refer to the author's 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 apps must run as root in containers, which is the best scenario for using user namespaces. We map a normal user (user with normal privileges) in the host to root in the container using user namespace technology. In the container, the user considers himself root in his user namespace and has various privileges of root, but for resources on the host machine, he only has very limited access rights (ordinary user).

User mapping of user namespace

Before configuring docker daemon to enable user namespace, I need to understand some concepts about subordinate users/groups and remappings. The mapping of dependent users and groups is controlled by two configuration files,/etc/suuid and/etc/subgroup. Before configuring docker daemons to enable user namespaces, I need to understand a few concepts about subordinating users/groups and remapping:

For suuid, this line of records means:

User nick has 65536 subordinate users in the current user namespace, with user ids of 100000-165535. In a child user namespace, these subordinate users are mapped to users with ids of 0-65535. Subgid has the same meaning as suuid.

For example, user nick is only a user with normal privileges on the host. We can assign one of its subordinate ids (say 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 in the host machine, you have at most nick user privileges.

When docker's support for user namespaces is enabled (docker's users-remap feature), we can specify different users to map to containers. For example, we create a user dockeruser, and then manually set its suuid and subgid:

nick:100000:65536dockeruser:165536:65536

And assign it to the docker daemon:

{ "userns-remap": "dockeruser"}

Please note that the subuid setting information for dockeruser and nick user does not overlap. In fact, the subid setting for any user cannot overlap.

Or simply let docker do all the heavy lifting for us and simply 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 I take a simple approach and let docker create default users for the user namespace. We need to create the/etc/docker/daemon.json file first:

$ sudo touch /etc/docker/daemon.json

Then edit its contents 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 examine a few points about user segregation.

First verify that docker creates a user named dockremap:

Then check to see if the new user dockremap entry has been added to the/etc/suuid and/etc/subgid files:

Next, we found that a new directory was created under/var/lib/docker directory: 165536.165536, and the permissions to view this directory:

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

It is basically the same as the contents in the/var/lib/docker directory, indicating that the contents related to files after enabling user isolation will be placed in the newly created directory 165536.165536.

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

uid in host vs. uid in container

After the docker daemon enables user isolation, let's look at the uid in the host versus the uid in the container.

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

uid 165536 is a subordinate id of the user dockremap and does not have any special permissions on the host. However, the user in the container is root, so the result looks perfect:

Newly created containers create user namespaces

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

The container process sleep in the image above is in the same user namespace as the process on the host (without user isolation enabled).

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

4404 in the above image 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 supreme power!

Access files in a data volume

We can prove exactly what privileges root has in the container by accessing files in the data volume. Create four files belonging to users root, 165536, and nick. rootfile Only root user can read and write, user nick has read and write permissions for nickfile, uid165536 has read and write permissions for file 165536, any user can read and write testfile file:

Here are a few files to mount as a data volume into the container, 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 on the host.

Disable user namespace in container

Once the "users-remap" parameter is set for the docker daemon, all containers will have user isolation enabled by default (creating a new user namespace by default). In some cases we may need to go back to a scenario where user isolation is not enabled. In this case, user isolation can be disabled for individual containers by using the--users =host parameter. -- The users =host parameter is used primarily for 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 progress information:

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

known issues

user namespace is a relatively advanced feature, docker support for it is not perfect at present, the following are known to be incompatible with existing features:

pid or net namespace of shared host (--pid=host or --network=host)

External storage and data volume drivers may not be compatible or support user namespace

Use--privileged without specifying--users =host

The content of "how to isolate users in docker container" is introduced here. Thank you for reading. If you want to know more about industry-related knowledge, you can pay attention to the industry information channel. Xiaobian will update different knowledge points for you every day.

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.