Build steps already run as root until a USER line changes that, so sudo is unnecessary during the build. Installing it and granting the runtime user sudo rights gives that non-root user a way back to root at run time, which undoes the protection USER was meant to provide. Do root steps before USER and give the app user ownership of only what it needs.
openrouting — dockerfile explainer
$ explain Dockerfile! RUN installs or uses sudo mediumline 2fix: see below$
What the free Dockerfile explainer reports on the risky example below.
Why it matters
A passwordless sudo rule for the app user means anyone who compromises the app can become root inside the container with one command.
sudo is unpredictable in containers: it expects a TTY and specific environment handling. Docker's best-practice guidance is to avoid it and use a tool such as gosu if an entrypoint really must drop privileges.
The explainer flags any RUN that mentions sudo as a command, whether it installs the package or calls it.
Remove sudo and any sudoers entries from the image.
Run every step that needs root before the USER line; RUN already runs as root there, so prefixing commands with sudo does nothing useful.
Give the runtime user ownership of the specific directories it writes to (chown), and nothing else.
If the entrypoint must start as root and then drop privileges, use a small tool such as gosu rather than sudo.
When it's acceptable
Development or devcontainer images where a person works interactively inside the container and needs to install tools. Don't ship those images to production.
Check your own Dockerfile
The risky example is loaded below. Paste your own file to check it for this and every other Dockerfile rule. It runs in your browser; nothing is uploaded.
Runs apt-get update && apt-get install -y --no-install-recommends sudo ca-certificates && rm -rf /var/lib/apt/lists/* && user… while building the image and saves the result as a new layer.
sudo gives a non-root user a way back to root, which undoes the point of a USER instruction.
Safer: Drop sudo. Do the steps that need root before the USER line, and give the runtime user ownership of only what it needs.
Sets the default command to /usr/local/bin/app. It runs when the container starts, and anything passed to docker run replaces it.
Questions
Do I need sudo in a Dockerfile?
No. RUN steps run as root unless an earlier USER changes that, so put root steps before USER instead of using sudo.
Why is sudo not found in my Docker build?
Most base images don't include it, because build steps already run as root. Remove the sudo prefix and place the step before your USER line.
What should I use instead of sudo in a Docker entrypoint?
If a script must do something as root and then run the app as another user, Docker's guidance suggests gosu. Better still, avoid needing root at run time at all.