In this lesson, we will explore the concept of running containers as a non-root user.

What is a Non-Root User?

A non-root user is a regular system user with restricted permissions. Unlike the root user, who has complete control over the system, a non-root user only has access to specific areas defined by system settings.

This means that a non-root user cannot create, modify, or delete files in other users directories unless explicitly given permission.

By default, non-root users don't have the ability to use powerful commands like sudo. However, you can configure them to run certain commands with elevated privileges if necessary.

Host root vs Container root

It is important to understand that the root user inside a container ("container root") is not the same as the root user on the host system. Let’s break this down with some examples to make the difference clearer.

Host Root User

The root user on the host system has complete control over all resources and processes on that system. The host root can access any files, run any commands, install or uninstall software, and change system configurations. Essentially, they are the ultimate administrator of the host.

Container Root User

The root user inside a container has similar privileges within the container.

Even though the container root user appears to be like the host root user, it is isolated in many ways. Container root (UID 0) is only root within the container's namespace.

This means that while it has root privileges within the container, it does not have direct access to the host system's resources unless explicitly allowed (e.g., through volume mounts or network configurations)

But there is still a risk: if a container running as root is compromised, there may be vulnerabilities that allow an attacker to break out of the container and gain host-level access.

This is why running containers as root is discouraged.

Minimizing Security Risks

If an attacker gains access to a container that is running as root, they could exploit container vulnerabilities to escape into the host system.

Once escaped, the attacker could potentially gain access to the host system with root-level privileges, especially if certain privileges have been shared between the host and container.

So following the Principle of Least Privilege, you only grant processes the permissions they need and nothing more.

For example,

If you configure your container to run as a user called appuser with limited permissions and an attacker gains access, they can only perform actions that appuser is allowed to do, which does not include modifying host settings or accessing sensitive files outside the container.

Note: Many security regulations and standards, such as PCI DSS (for payment security) and HIPAA (for healthcare data protection), require that applications run with the least privilege possible. Using non-root users in Docker aligns with these requirements and ensures a safer environment.