Why Running Docker Containers as Root Is Risky and How to Use the Privileged Flag Safely

Many Unix users habitually elevate privileges with sudo to become root, especially when debugging tools or editing protected files inside containers. While convenient, this practice can expose containers to unnecessary risks.

Running Containers as Root

By default most Docker images run as the root user. Simple examples with popular images show this behavior:

$ docker run -it postgres
# whoami
root
# id -u
0

$ docker run -it couchbase sh
# whoami
root
# id -u
0

$ docker run -it alpine sh
# whoami
root
# id -u
0

Although running as root simplifies debugging, it violates the principle of least privilege and can allow a compromised container to affect the host.

How to Avoid Running as Root

Specify a non‑root user in the Dockerfile

// Dockerfile
FROM microsoft/windowsservercore
# Create a Windows user in the container
RUN net user /add patrick
# Use it for subsequent commands
USER patrick

Override the user at runtime

$ docker run -it --user 4000 postgres sh
# whoami
whoami: cannot find name for user ID 4000
# id -u
4000

Understanding the --privileged Flag

The --privileged flag maps the container’s user ID directly to the host’s ID and grants unrestricted access to system calls. Even though the container runs as root, Docker still limits certain capabilities (e.g., CAP_AUDIT_WRITE).

Using the flag can let a container change the host’s hostname or sysctl settings, which would otherwise be blocked:

# Without privileged
$ docker run -it ubuntu sh
# sysctl kernel.hostname=Attacker
sysctl: setting key "kernel.hostname": Read-only file system

# With privileged
$ docker run -it --privileged ubuntu sh
# sysctl kernel.hostname=Attacker
kernel.hostname = Attacker

Because it effectively gives the container root‑level access to the host, --privileged should only be used for specific use‑cases such as Docker‑in‑Docker, certain CI/CD pipelines, or extreme networking requirements.

Kubernetes Equivalent

Kubernetes provides the same capability via securityContext.privileged in a pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
    securityContext:
      privileged: true

Additionally, a PodSecurityPolicy can enforce that privileged pods are disallowed:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false # Don't allow privileged pods!

Conclusion

The article covered the security implications of using root and the --privileged flag in Docker and Kubernetes, emphasizing that avoiding root, avoiding privileged mode, and applying SecurityContext and PodSecurityPolicy are key steps toward stronger container security.

Original source: https://itnext.io/docker-and-kubernetes-root-vs-privileged-9d2a37453dec