kras99 - stock.adobe.com
Docker's rootless mode a welcome security update
Docker containers have root privileges by default -- a known security issue for several years. Now Docker's rootless mode separates containers from underlying infrastructure.
When Docker first came about, it had a serious architectural issue. Docker containers are lightweight because they share an underlying OS, unlike virtual machines, which each contain their own copy.
To access this underlying OS and its various functions and services, Docker containers originally needed to use a daemon -- part of the Docker Engine -- that ran with root privileges. Via the daemon, containers could have full privileges through not only the container itself but also the underlying platform.
If a malicious actor compromised a poorly constructed container, they could use this root access to bypass the security audit function, leading to devastating consequences such as exposure, theft or loss of business data. They could also take direct control of the daemon itself, with similarly catastrophic results.
Step away from the underlying infrastructure
To counteract this, Docker Engine introduced a rootless mode as an experimental feature in version 19.03, which became generally available in December 2020 as part of version 20.10. Rootless mode -- which represents a major step forward in Docker container security -- creates a less-privileged, nonroot daemon. This daemon can build a full Docker Engine and container stack without root privileges, forming a more secure environment.
Docker's rootless mode is well suited for IT admins running common containers with general access permissions, particularly when access is available to users outside the organization. This external access increases the organization's attack surface and the likelihood of a privileged attack.
Running Docker in rootless mode requires extra work, however. For example, internet access is not available directly in a rootless environment. IT admins create that connection via mapping, with small effects on overall performance.
Rooted mode presents a larger set of security issues, although many can be addressed by practicing good code hygiene when setting up the Docker environment. Because rootless mode is still evolving, there are also situations wherein rooted mode might be necessary -- for example, Docker Swarm is not currently supported in rootless environments.
Using rootless mode runs both the Docker container and daemon within a defined user namespace. This enables the daemon to run without root privileges, unlike in userns-remap mode. Userns-remap enables certain aspects of the container to run in nonprivileged mode but forces others to use root privileges. Rootless mode, in contrast, removes all root-privileged access.
Not all Docker containers are suitable or ready for rootless mode operation. For example, any container with binaries containing SETUID bits or file capabilities -- barring a few exceptions -- cannot run in rootless mode. These exceptions are newuidmap and newgidmap, which are both necessary to set up both multiple user IDs (UIDs) and group IDs (GIDs).
Rootless mode requires at least 65,536 subordinate UIDs or GIDs to operate. These UIDs and GIDs remap calls and responses between the Docker daemon and containers.
When using a standard Docker instance, the daemon talks directly to the root of the kernel. In userns-remap mode, the daemon still runs certain aspects as root, but the containers remap through UIDs and GIDs within a specified namespace to interact with it. In rootless mode, the daemon and containers all interact via UIDs and GIDs within the same namespace.
Other areas will not work unless the container is started with root privileges -- for example, when starting an Azure Databricks cluster with a custom Docker container. Containers that require direct access to network-attached devices generally must run with root access capabilities or in privileged mode, a particularly powerful and potentially dangerous mode that gives the container full access to the underlying kernel.
Certain actions are not supported in rootless mode: Only a subset of storage layers can be used; different approaches must be used for pinging, which exposes TCP and UDP ports below 1024; and the IP address of the system cannot be accessed without additional code. Another constraint is that cgroup version 2 must be used for security reasons -- any container using cgroup version 1 will not work in rootless mode.
The Docker ecosystem is increasingly supporting rootless environments. As of version 1.22, Kubernetes supports rootless mode and can run in a nonprivileged mode itself.
Podman -- an alternative approach to containerization that is part of Red Hat Linux -- operates a daemonless approach that supports rootless containers by default. Podman can be installed on other Linux distributions in addition to Red Hat and is compatible with Open Container Initiative, so it can be used as a drop-in replacement for the Docker runtime.
For those still running Docker containers in rooted mode, it's time to move as many as possible over to rootless. Doing so is simple and will provide much greater security and peace of mind.
