Why is running a container as root dangerous even though it is isolated?
Root inside a container is still UID 0 on the shared host kernel. A kernel bug, a bad mount or extra capabilities can let an attacker turn that into host access. Running as non-root removes much of that risk.
Explain it simply
A container is not a separate building; it is a locked room in the same building, sharing the same foundation, the kernel. Root in the room still holds a powerful key to the same locks.
UID 0 inside a container is UID 0 to the kernel unless user namespaces remap it. If the app has a code-execution bug and also a writable bind mount of /etc or the Docker socket, or a kernel vulnerability exists, root makes escape or damage far easier. A non-root user cannot install packages, write system files, bind low ports or change ownership, so many attacks stop early.
Good practice: add a USER instruction, drop capabilities, use a read-only filesystem and avoid --privileged. Kubernetes enforces this with securityContext.runAsNonRoot: true.
Example
# Kubernetes pod spec snippet
securityContext:
runAsNonRoot: true
runAsUser: 10001
allowPrivilegeEscalation: false
readOnlyRootFilesystem: trueWhat to say in the interview
"Containers share the host kernel, so root inside is a real risk if there is an exploit, a dangerous mount or extra capabilities. I run as a non-root user, drop capabilities, and use a read-only root filesystem."
Common mistakes
- Believing that containers are as isolated as virtual machines.