Rootless Docker - Run Containers Without Root

A Docker daemon running as root means anything that can talk to that daemon can effectively root the host. Interviewers bring this up to see if you understand the actual attack surface of a container runtime, not just the buzzword "rootless."

The answer interviewers want

By default, the Docker daemon runs as root, and a container breakout or a compromised daemon socket gives an attacker root on the host. Rootless Docker fixes this by running the daemon itself as a regular, unprivileged user. Your containers still build, run, and behave normally, but the daemon process has no root privileges to abuse in the first place.

To set it up, install it with dockerd-rootless-setuptool.sh. Once it's running, export DOCKER_HOST to point at your user-level socket instead of the default system socket, so the docker CLI talks to your rootless daemon.

The detail most people miss: because the daemon has no root privileges, it can't bind to privileged ports, meaning anything below 1024. So if you're used to mapping -p 80:80 or -p 443:443, that won't work under rootless mode. You need to plan your port mappings around this, usually by mapping to a high port on the host and putting a reverse proxy in front, or mapping to unprivileged ports directly in your app config.

With that constraint accounted for, rootless Docker gives you a daemon and container runtime that no longer need root to operate, which closes off one of the most common container escape paths.

Why interviewers ask this

This question separates people who've memorized "run containers as a non-root user" from people who understand the daemon itself is the real privilege-escalation risk. They want to know if you can reason about attack surface, not just recite a Dockerfile USER directive. It also tests whether you've actually operated rootless mode and hit its real-world limitations, like the port restriction.

Follow-ups to expect

• How do you expose a rootless container on port 443 then? You map to a high unprivileged port on the host and put a reverse proxy, load balancer, or iptables/systemd socket activation in front of it to forward traffic from 443.
• Does rootless Docker change anything inside the container itself? No, the source doesn't change container behavior; the containers still run the same, the difference is the privilege level of the daemon process on the host.
• What's the actual security benefit here? If the daemon or a container escapes, the blast radius is limited to a regular user's permissions instead of root, since the daemon was never running as root to begin with.

The common wrong answer

Most candidates answer this with USER appuser in a Dockerfile and stop there. That only controls the user inside the container process; it says nothing about the daemon, which is still root-owned and still the bigger risk. Interviewers are listening for whether you mention the daemon itself, the setup tool, and the privileged-port tradeoff, not just container-level user switching.