Root vs Privileged in Docker/Kubernetes: Risks and Safe Alternatives

Many Unix users habitually elevate privileges with sudo or run commands as the root user inside containers, which can introduce unnecessary security risks. Docker containers often run as root by default, and Docker offers a --privileged flag that grants the container almost unrestricted access to the host.

Root Default in Popular Images

Running three common images shows they all start as root:

$ 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

While this simplifies debugging, it violates the principle of least privilege and can expose the host if the container escapes.

How to Avoid Running as Root

Specify a non‑root user in the Dockerfile:

// Dockerfile
FROM microsoft/windowsservercore
# Create Windows user in the container
RUN net user /add patrick
# Set 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

What the --privileged Flag Does

The flag maps the container's user ID directly to the host's ID and removes most capability restrictions, allowing actions such as changing the host's hostname or modifying kernel parameters.

Example Without Privilege

# whoami
root
# id -u
0
# hostname
382f1c400bd
# sysctl kernel.hostname=Attacker
sysctl: setting key "kernel.hostname": Read-only file system  # operation blocked

Example With --privileged

$ docker run -it --privileged ubuntu sh
# whoami
root  # Root again
# id -u
0
# hostname
86c62e9bba5e
# sysctl kernel.hostname=Attacker
kernel.hostname = Attacker  # operation succeeds
# hostname
Attacker

Kubernetes Equivalent

Kubernetes can grant the same capability via securityContext.privileged:

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

However, the platform also provides PodSecurityPolicy to enforce the opposite, disallowing privileged pods:

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

Conclusion

Understanding the relationship between root and the --privileged flag is essential for container security. Avoiding root and privileged execution, using USER in Dockerfiles, runtime --user overrides, and applying Kubernetes securityContext and PodSecurityPolicy are four key practices for a deeper, defense‑in‑depth posture.