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.

Host root vs Container root

Host root and Container root are not same in terms on host resource access.

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.

Note: Container root (UID 0) is the same as host UID 0 unless user namespaces are explicitly configured.

This means that while it has root privileges within the container, it does not have direct access to the host system's resources due to Namespace, Control groups and security profiles like seccomp.

Meaning, The container runtime removes some special permissions (called capabilities) and blocks certain system calls (using seccomp) to make the container environment more secure, even though the user ID (UID) remains the same inside the container and on the host.

For example,

However, if you explicitly allow privileges through capabilities or the --privileged flag, the container root will have access to the host (e.g., through volume mounts or network configurations).

You can directly mount host filesystems, change host kernel parameters, write to system files, and access or modify them.

For example,

Now, let’s say you are running a container without privileged mode.

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

This is why running containers as root is strongly discouraged.