Rootless Containers Are Generating a Buzz in the Industry. Here’s Why

In recent years, containers have become increasingly popular among developers as they let you narrow your focus to a single application logic unit and its dependencies without worrying about contextual details like software versions or configurations. As per industry estimatesOpens a new window , container usage grew from just 23% in 2016 to 84% in 2019. However, containerization comes with its security challenges – among which user privileges and privileged flags are a major concern. Privileged flags indicate that the container is granted all of the host’s access rights, making them a prime target for attackers. 

The question, therefore, is this – what if you could run containers without a privileged flag or without root privileges at all? That’s what the concept of a rootless container aims to achieve. 

A rootless container lets users run a container with all the privileges necessary for proper functioning and app development without access-related security vulnerabilities. Given that container security is the #1 priority for nearly 1 in 3 companiesOpens a new window using containerization, rootless containers hold incredible potential for the industry. 

Learn More:  VMware Deploys New Virtual Containers for Cloud Migrations  

What is a Rootless Container and Why is it Necessary? 

The origins of rootless containers can be traced back to the chroot system call, which was introduced in 1979 to enable the changing of a process’s root directory and any child processes. Rootless containers got a leg up recently, as the globally recognized Docker platform introduced the rootless mode in 2019. Rootless containers in Docker were graduated from an experimental stage in V20 of the platform, mainstreaming it more than ever before. 

If we consider how rootless containers work, it immediately becomes clear why they hold such promise for container security. 

Typically, when you run a container, the default mode is that the user has root privileges, and the root inside the container is the same as the root on the host machine. Unless the user ID is changed manually, the root inside the container will be able to access the entire host machine environment – creating myriad security risks. 

But you can’t really utilize containers without root privileges. This privileged status allows developers to perform advanced functions inside the container without any restrictions, like installing system packages, editing configuration files, etc. Simply put, non-root containers cannot fulfill the entire set of requirements that an advanced app dev team will bring to the table. 

Rootless containers neutralize the risks of holding privileges while continuing to allow users unrestricted container access. Inside a rootless container, the code appears to be running as root and can therefore perform privileged tasks that would otherwise not be permitted. But the host sees the container as a regular user and does not acknowledge any privileges. If a hacker does manage to break into the container, they will not be able to carry forward any root privileges to the host machine. This dramatically shrinks your risk vector. 

Learn More:  What Is Container Security? Definition, Components, Best Practices, and Software 

Why Rootless Containers Are More Secure 

As discussed, rootless containers combine the freedom of unrestricted operations in a containerized environment with least-privilege access in the host. There are four ways in which it enables this: 

1. An additional protection surface  

A rootless container acts as an additional security layer between the container engine and the host machine. In a rootless container, a user namespace (a key Linux component) is used to map the user ID(s) in a manner that processes appear different from inside the container and wholly different to the host. In a rootless container, this user namespace component adds an additional layer of security, protecting the host from unauthorized root privileges even if the container engine or orchestrator is breached. 

2. Multiple users, same security 

As we mentioned in the previous point, you can have multiple user IDs or even a group of IDs in a single user namespace. Any user, even without privileges, can run containers without having root privilege access to the host. This lets you add multiple users to containers on the same host machine simultaneously, without multiplying your threat vector with every new user you add. Multiple underprivileged users can together enable a high-performance application development environment with minimal impact on security. 

3. Secure spaces inside nested containers 

In a nested container environment, you can have multiple rootless containers that are isolated from each other and from their surrounding environment. A traditional root container, even if the inside of another container wouldn’t be truly isolated as explicit root privileges would apply to the conditioner and its surrounding host or nesting container environment. A rootless mode solves this effectively by snipping the chain of privileges. 

4. More open access with fewer risks 

A big difference between regular containers and rootless containers is the level of user privilege needed to create them. Traditionally, a user had to mandatorily bring root privileges to the host in order to create a default root container. This meant that either a smaller, more restricted set of users could create containers, or you would have to constantly compromise on security to allow more users in. In comparison, rootless containers can be created by users without root access, minimizing risk and access complexity. 

Leveraging Rootless Containers and Key Considerations

Rootless containers are only just gaining momentum, and the launch of Docker V20 was an important step in the right direction. But widespread industry support for rootless containers still lacks – most prominently, in the Kubernetes environment. Currently, rootless containers in Kubernetes are still at a proof of concept stage under a project called Usernetes. However, you will find the occasional containerization enabler and tool to help you in your quest for rootless container applications. Singularity and Podman (by RedHat) are two popular providers, and there’s Buildah, Umoci, and udocker as well – in addition to the new Docker feature. 

But do keep in mind that, given the non-mature state of rootless containers, there will be a couple of key considerations: 

• Changing the user namespace component could impact container functionality and cause errors in certain environments and tasks. One developer observedOpens a new window that when a user attempted to run Plex (a media server) in a container as rootless, it turned up an error, indicating that permission was denied. There might be a rare issue with functionality in a rootless mode. 
• Rootless containers aren’t very widely tested as yet and could come with their own security vulnerabilities. There might be issues with privilege escalation, which need to be reviewed and addressed for each tool and environment.

Having said that, there is no denying that rootless containers signal a new era of more secure application development. 63%Opens a new window of companies using containerization said they would be willing to curtail security in exchange for high-velocity production. As rootless containers become more mainstream, such trade-offs are no longer necessary. 

Have you leveraged rootless containers at your organization? Comment below or let us know on LinkedInOpens a new window , TwitterOpens a new window , or FacebookOpens a new window . We would love to hear from you!