root in Docker container" why it matters and the fix

"root in Docker container" why it matters and the fix

TL;DR

Containers run as root by default, and root in a container is one misconfigured mount or kernel bug away from root on the host. The fix: create a non-root user in the Dockerfile and switch to it with USER, drop unneeded capabilities, run the filesystem read-only, and set no-new-privileges. Four small changes that turn a container escape from "game over" into "contained."

"root in Docker container" why it matters and the fix

Use this when

• A scan flags containers running as root
• You are hardening Dockerfiles before production
• You need to explain to a team why root-in-container matters
• You are writing container security standards

Not for this skill when

• You need Kubernetes pod security configuration (related but separate)
• The task is general Dockerfile size or speed optimization
• You are hardening the host OS itself

Steps

1. Check what user your containers actually run as

Look at the Dockerfile for a USER line, and check a running container. No USER line means root.

grep -i "^USER" Dockerfile; docker exec [container-name] whoami

Expected: either a USER line naming a non-root user and whoami printing that name, or no USER line and whoami printing root. Root is the finding; everything after this step fixes it.

2. Add a non-root user and switch to it

Create the user early in the Dockerfile, fix ownership of the app files, and set USER before the container starts doing work. Do it near the end so build steps that need root still work.

RUN useradd -m -u 10001 appuser && chown -R appuser:appuser /app
USER appuser

Expected: rebuilt images run the app as appuser; docker exec [container] whoami prints appuser. Use a fixed UID so Kubernetes runAsUser and volume permissions stay consistent across rebuilds.

3. Drop capabilities you dont need

Even non-root containers keep a bundle of Linux capabilities; most apps need none of them. Drop them all and add back only what breaks.

docker run --cap-drop=all --cap-add=CHOWN --read-only --tmpfs /tmp [registry]/[image]:[tag]

Expected: the container starts and the app works. If it fails, the error names the missing capability; add back only that one. Fewer capabilities means a compromised process can do less with its privileges.

4. Make the filesystem read-only and block privilege escalation

A read-only root filesystem stops malware from writing binaries and configs; no-new-privileges stops a process from gaining more privilege via setuid tricks. Mount a tmpfs for the scratch space the app genuinely needs.

docker run --read-only --tmpfs /tmp --security-opt=no-new-privileges:true [registry]/[image]:[tag]

Expected: the container runs; writes outside the tmpfs mounts fail. If the app needs a writable data dir, mount a volume for exactly that path instead of making everything writable.

5. Verify the whole setup together

Inspect the running container's user, capabilities, and mount flags in one pass, and confirm the app still serves traffic.

docker exec [container-name] sh -c 'whoami; id; cat /proc/1/status | grep -i cap'

Expected: non-root user, reduced capability set. Hit the app's health endpoint to confirm it serves traffic; hardening that breaks the app gets reverted by the next person in a hurry.

Variant: dockerfile USER best practice

Put USER after all root-requiring build steps, chown the app directory to the runtime user, and never switch back to root later in the file. In multi-stage builds, create the user in the final stage; users dont carry over from builder stages.

Variant: app needs to bind port 80 as non-root

Non-root users cant bind ports below 1024. The clean fixes: listen on 8080 in the container and map the host port, or grant just the NETBINDSERVICE capability. Dont go back to root for a port number.

Variant: rootless docker vs USER directive

Rootless Docker (daemon running as non-root) and USER (process running as non-root) solve different halves: rootless protects the host from the daemon, USER protects the host from the container process. Use both; neither replaces the other.

Why this happens

Docker inherited root-by-default from its build-tool origins, where root made everything simpler. In production that default means every container process wields host-level privilege boundaries enforced only by namespaces and cgroups, which have had escape bugs before. Running as non-root doesnt fix kernel bugs, but it makes most escape paths dead ends instead of host takeovers.

Edge cases and pitfalls

• File ownership on volumes: host-mounted volumes owned by root are unreadable to appuser; chown the mount or set the volume's ownership at creation.
• Package managers at runtime: pip or npm installs at container start need write access; do installs at build time instead.
• Debugging without a shell user: non-root plus distroless means no shell for exec debugging; keep a debug image variant for incidents.
• UID collisions with host: a container UID matching a privileged host UID matters only if user namespaces are off; turn user namespaces on too.
• Legacy images you cant rebuild: apply the runtime flags (user, cap-drop, read-only) at run time as a stopgap while you rebuild the image properly.
• Health checks as root: orchestrator exec probes run as the container user; make sure the probe command works without root.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2AOPZceTgjtr1kvGPrRqlQ