Running Non-Root User in Docker: Security Best Practice for Java

Intermediate·2 min read·

Fast recall

Quick revision

Core answer

Running as root in Docker is a security risk — if the container is compromised, the attacker has root access to the container filesystem and potentially the host if the container escapes. Create a dedicated user in the Dockerfile with RUN adduser, set it with USER instruction before ENTRYPOINT, and ensure the application directory is owned by that user.

Interview Answer2 min

By default, Docker containers run as root inside the container. If a vulnerability in your application allows container escape, a root container gives an attacker far more capability than a non-root process would. The fix is two lines in your Dockerfile.

Creating and using a non-root user

In the runtime stage of your Dockerfile, add RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser then USER appuser — all subsequent instructions and the CMD run as that user
The application directory must be owned by the non-root user: COPY --chown=appuser:appgroup target/app.jar /app/app.jar — without the --chown, the binary is owned by root and the non-root process cannot read it
Use a specific numeric UID in Kubernetes environments with PodSecurityContext: runAsUser: 10001 — Kubernetes admission controllers and PSP/PSA configurations often require non-root UIDs, and named users are only meaningful within the container's own /etc/passwd

File permission requirements

A Spring Boot application with an embedded Tomcat writes temporary files to the system's temp directory by default — ensure the non-root user has write access to /tmp or configure server.tomcat.basedir to a path the user owns
JVM crash logs and heap dumps require a writable directory; set -XX:ErrorFile=/tmp/hs_err_%p.log and -XX:HeapDumpPath=/tmp/heap_dump.hprof to paths the appuser can write
The most common runtime failure after adding a non-root user: the application tries to write to a path owned by root and throws java.io.IOException: Permission denied — test the container explicitly with docker run --user appuser before pushing to production

Defense in depth

Non-root is one layer; also combine it with read-only filesystem (--read-only flag), dropped Linux capabilities (--cap-drop=ALL), and no-new-privileges (--security-opt no-new-privileges=true) for a hardened production container
These controls together prevent an attacker from writing executables, escalating privileges, or loading kernel modules even if they achieve code execution inside the container

Interview-ready guide

Interview answer

Creating and using a non-root user

In the runtime stage of your Dockerfile, add RUN addgroup --system appgroup && adduser --system --ingroup appgroup appuser then USER appuser — all subsequent instructions and the CMD run as that user
The application directory must be owned by the non-root user: COPY --chown=appuser:appgroup target/app.jar /app/app.jar — without the --chown, the binary is owned by root and the non-root process cannot read it
Use a specific numeric UID in Kubernetes environments with PodSecurityContext: runAsUser: 10001 — Kubernetes admission controllers and PSP/PSA configurations often require non-root UIDs, and named users are only meaningful within the container's own /etc/passwd

File permission requirements

A Spring Boot application with an embedded Tomcat writes temporary files to the system's temp directory by default — ensure the non-root user has write access to /tmp or configure server.tomcat.basedir to a path the user owns
JVM crash logs and heap dumps require a writable directory; set -XX:ErrorFile=/tmp/hs_err_%p.log and -XX:HeapDumpPath=/tmp/heap_dump.hprof to paths the appuser can write
The most common runtime failure after adding a non-root user: the application tries to write to a path owned by root and throws java.io.IOException: Permission denied — test the container explicitly with docker run --user appuser before pushing to production

Defense in depth

Non-root is one layer; also combine it with read-only filesystem (--read-only flag), dropped Linux capabilities (--cap-drop=ALL), and no-new-privileges (--security-opt no-new-privileges=true) for a hardened production container
These controls together prevent an attacker from writing executables, escalating privileges, or loading kernel modules even if they achieve code execution inside the container

03 · Deep dive