Introduction
Docker privileged is one of many useful features of this powerful virtualization platform. Before you start working in privileged mode, make sure you understand how it works.
In this tutorial, you will learn what privileged Docker containers are, when to use them, and whether it is a good option for you.
What is Docker Privileged Mode?
Docker privileged mode grants a Docker container root capabilities to all devices on the host system. Running a container in privileged mode gives it the capabilities of its host machine. For example, it enables it to modify App Arm and SELinux configurations.
With the host’s kernel features and device access, you can even install a new instance of the Docker platform within the privileged container. Essentially, this mode allows running Docker inside Docker.
Note: Learn more about Docker containers and how they differ from Docker images in Docker Image Vs Container: The Major Differences.
How to Check if a Container is Privileged?
To check whether you are running a container in privileged mode, use the command:
docker inspect --format='{{.HostConfig.Privileged}}' [container_id]If the container is privileged, the output responds with true, as in the image below.
On the other hand, if the container is not privileged, the output displays the message false.
How to Run Docker Privileged Mode?
Instruct Docker to run a container in privileged mode by adding the --privileged option to the run command:
sudo docker run --privileged [image_name]Docker Privileged Example
To run an Ubuntu container (interactively) in privileged mode, you would use:
sudo docker run -it --privileged ubuntuTo test whether the container has access to the host, you can try to create a temporary file system (tmpfs) and mount it to /mnt:
mount -t tmpfs none /mntNow, list the disk space statistics (in human readable format) with the command:
df -hThe newly created file system should appear on the list, as in the image below.
Why Running Privileged Containers is Not Secure?
Just like Ubuntu discourages using the system as root, so does Docker. Exposing the kernel and the hardware resources of the host to any outside cyberattack is always a potential threat to the system.
For this reason, it is not recommended to use privileged containers in a production environment.
Possible Breaches Via Privileged Containers
Having privileged containers is a security risk for any organization. It creates opportunities for malicious users to take control of the system.
Allowing a container root access to everything on the system opens a window of opportunity for cyberattacks. A cyberattacker could connect to the host from the container and endanger the established infrastructure and configuration.
The most common scenario is when a legitimate user abuses the given privilege for malicious activity.
How to Minimize Docker Container Privilege Escalation?
The best way to prevent Docker container privilege escalation is not using privileged containers at all.
However, if you are running an application that requires executing with the root user, there is a way to minimize the chances of malicious activity. This is done by user namespace remapping, re-mapping the user for that specific container to a less-privileged user on the Docker host. Essentially, the container views the user as the root, while the host does not.
Re-mapping includes assigning a range of UIDs that function within the container (namespace) as normal UIDs from 0 to 65536 yet have no privileges on the host. Two files manage the user configuration – one for the user ID range (/etc/subuid) and the other for the group ID range (/etc/subgid).
By default, docker uses the dockremap user and group to make the remapping.
Note: For more details on working with Docker containers, refer to best practices for managing Docker containers.
Conclusion
After reading this article, you should know that running privileged Docker containers is not the safest option. However, if you cannot avoid doing so, make sure you protect the host to prevent potential breaches.
