Docker Run as Non-Root - Stop This Bad Practice

A container that runs as root isn't just a container problem. If an attacker breaks out of it, they land on your host with full privileges. This question shows up in almost every Docker and Kubernetes security interview because it separates people who've read about containers from people who've had to lock one down.

The answer interviewers want

Root inside a container is still root if there's a container breakout. A root container has full host access, and if someone escapes it, they own your entire system. That's the baseline risk you're removing by running as an unprivileged user.

The standard fix lives in your Dockerfile: create a user, then switch to it before the container starts running your application. Order matters here. You install packages and do your setup as root first, because package managers and system configuration usually need those privileges, and only then do you drop down:

RUN groupadd -r appgroup && useradd -r -g appgroup appuser
# install packages, copy files, etc. as root
USER appuser

The detail most people miss: use a numeric UID instead of a username in the USER directive. Something like USER 1000 instead of USER appuser. The reason is practical, not stylistic. Kubernetes sometimes can't resolve usernames across different base images, especially when your pod's security context or another layer in the chain expects a UID and the name doesn't map cleanly. A numeric UID is unambiguous no matter what base image or orchestrator is reading it.

Why interviewers ask this

This question tests whether you treat container security as a default, not an afterthought. Anyone can say "don't run as root." Fewer people know why the USER directive has to come after package installation, and fewer still know about the UID-versus-username gotcha, which only shows up once you've actually run workloads across mixed base images in Kubernetes.

Follow-ups to expect

What happens if an application needs to bind to a low port like 80 as a non-root user? You'd typically have it listen on an unprivileged port like 8080 and let a reverse proxy, load balancer, or Kubernetes service handle the port mapping, since non-root users can't bind to ports below 1024.

How do you enforce this across a whole cluster, not just one Dockerfile? You'd push toward policy enforcement at the Kubernetes layer, using a pod security context or policy controller to reject images that try to run as root, rather than trusting every Dockerfile to get it right.

Why not just rely on usernames since they're more readable? Because readability doesn't help you when a username fails to resolve across different base images, and a broken UID mapping can silently cause permission errors that are hard to debug in a cluster.

The common wrong answer

Most candidates stop at "add a USER line to the Dockerfile" and call it done. That answer misses the ordering requirement, skips the numeric UID detail entirely, and shows no awareness that the same Dockerfile can behave differently once it's running inside Kubernetes rather than standalone Docker.