Running containers as a non-root user is one of the key best practices in container security. It helps prevent attackers from gaining host-level control if a container is ever compromised.

Let’s understand this clearly.

A non-root user is simply a regular system user who does not have administrative (root) privileges. They can perform basic tasks but cannot modify system files or affect other users’ data unless explicitly granted permission.

It is also important to understand that host root and container root are not the same in terms of how much control they have over system resources.

Let’s break this down with some examples to make the difference clearer.

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.

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.