Should I run things inside a docker container as non root for safety?

Question

I already run my docker build and docker run without sudo. However, when I launch a process inside a docker container, it appears as a root process on top on the host (not inside the container).

While it cannot access the host filesystem because of namespacing and cgroups from docker, is it still more dangerous than running as a simple user?

If so, how is the right way of running things inside docker as non root?

Should I just do USER nonroot at the end of the Dockerfile?

UPDATE:

root it also needed for building some things. Should I put USER on the very top of the Dockerfile and then install sudo together with other dependencies, and then use sudo only when needed in the build?

Can someone give a simple Dockerfile example with USER in the beggining and installing and using sudo?

Answer 1

Running the container as root brings a lot of risks. Although being root inside the container is not the same as root on the host machine (some more details here) and you're able to deny a lot of actions already during startup, it is still the recommended approach.

Usually it's a good idea to use the USER directive after you install some general packages/libraries. In other words - after the operations that require root privileges. I don't recommend installing sudo inside an image - it's usually not needed. Always make sure that the user you specify has access to the files you need. Usually you don't need to create the user beforehand, but if you need something custom, you can always do that.

Here's an example Dockerfile for a Java application that runs under user my-service:

FROM alpine:latest
RUN apk add openjdk8-jre
COPY  ./some.jar /app/
ENV SERVICE_NAME="my-service"

RUN addgroup --gid 1001 -S $SERVICE_NAME && \
    adduser -G $SERVICE_NAME --shell /bin/false --disabled-password -H --uid 1001 $SERVICE_NAME && \
    mkdir -p /var/log/$SERVICE_NAME && \
    chown $SERVICE_NAME:$SERVICE_NAME /var/log/$SERVICE_NAME

EXPOSE 8080
USER $SERVICE_NAME
CMD ["java", "-jar", "/app/some.jar"]

As you can see, I create the user beforehand and select its gid, disable its shell and password, as it is going to be a 'service' user.

Answer 2

You can check out the CIS benchmark for Docker and they recommend to use non-root and this is one of the "Compliance" checks. Adding USER non-root at the bottom should suffice or you can use '-u' with your RUN command to specify user as well.

https://www.cisecurity.org/benchmark/docker/ https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

Answer 3

Why you shouldn't run as root

While other people have pointed out that you shouldn't run images as root, there isn't much information here, or in the docs about why that is.

While it's true that there is a difference between having root access to a container and root access on the host, root access on a container is still very powerful.

Here is a really good article that goes in depth on the difference between the two, and this issue in general:

https://www.redhat.com/en/blog/understanding-root-inside-and-outside-container

The general point is that if there is a malicious process in your container, it can do whatever it wants in the container, from installing packages, uploading data, hijacking resources, you name it, it can do it.

This also makes it easier for a process to break out of the container and gain privileges on the host since there are no safeguards within the container itself.

How and when to run as non-root

What you want to do is run all your installation and file download/copy steps as root (a lot of things need to be installed as root, and in general it's just a better practice for the reasons I outline below). Then, explicitly create a user and grant that user the minimum level of access that they need to run the application. This is done through the use of chmod and chown commands.

Immediately before your ENTRYPOINT or CMD directive, you then add a USER directive to switch to the newly created user. This will ensure that your application runs as a non-root user, and that user will only have access to what you explicitly gave it access to in previous steps.

The general idea is that the user that runs the container should have an absolute minimum of permissions (most of the time the user doesn't need read, write, and execute access to a file). That way, if there is a malicious process in your container, its behavior will be as restricted as possible. This means that you should avoid creating or copying in any files, or installing any packages as that user too, since they would have complete control over any resources they create by default. I've seen comments suggesting otherwise. Ignore them. If you want to be in line with security best practices, you would then have to go back and revoke the user's excess permissions, and that would just be awful and error prone.