Why Running Docker Containers as Root Is Dangerous and How to Avoid It

Many Unix users habitually elevate privileges with sudo to become the root user inside containers for debugging or editing protected files. While convenient, this practice can introduce serious security risks because most Docker images run as root by default.

Root Is the Default in Popular Images

Running a few widely‑used images shows the default user is root (UID 0):

$ 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

Because the default user is root, commands that require elevated privileges work out‑of‑the‑box, but this also violates the principle of least privilege and expands the attack surface.

Why Avoid Running as Root

Running as root inside a container can:

Break the least‑privilege model.

Cause the container to share the host’s user namespace, giving it access to host resources such as volumes and sockets if it escapes.

Two Ways to Avoid Root

1. Specify a Non‑Root User in the Dockerfile

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

2. Override the User ID at Runtime

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

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, effectively giving the container root‑level capabilities on the host. It should be used only for specific scenarios such as Docker‑in‑Docker, certain CI/CD pipelines, or extreme networking requirements.

Example: Ubuntu Without Privilege

# whoami
root  # still root inside the container
# id -u
0
# hostname
382f1c400bd
# sysctl kernel.hostname=Attacker
sysctl: setting key "kernel.hostname": Read‑only file system

Example: Ubuntu With --privileged

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

Kubernetes Equivalent

Kubernetes provides the same capability via securityContext.privileged and can enforce non‑privileged pods with PodSecurityPolicy:

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

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  privileged: false  # Do not allow privileged pods!

Conclusion

The article demonstrates that most Docker images run as root by default, explains the security implications of the --privileged flag, and offers concrete steps—using a non‑root user in Dockerfiles, overriding the UID at runtime, and applying Kubernetes security contexts—to reduce the attack surface and improve container security.