Docker - is it safe to switch to non-root user in ENTRYPOINT?
I just looked through what relevant literature (Adrian Mouat's Docker, Liz Rice's Container Security) has to say on the topic and added my own thoughts to it:
The main intention behind the much cited best practice to run containers as non-root is to avoid container breakouts via vulnerabilities in the application code. Naturally, if your application runs as root and then your container has access to the host, e.g. via a bind mount volume, a container breakout is possible. Likewise, if your application has rights to execute system libraries with vulnerabilities on your container file system, a denial of service attack looms.
Against these risks you are protected with your approach of using runuser
, since your application would not have rights on the host's root file system. Similarly, your application could not be abused to call system libraries on the container file system or even execute system calls on the host kernel.
However, if somebody attaches to your container with exec
, he would be root, since the container main process belongs to root. This might become an issue on systems with elaborate access right concepts like Kubernetes. Here, certain user groups might be granted a read-only view of the cluster including the right to exec into containers. Then, as root, they will have more rights than necessary, including possible rights on the host.
In conclusion, I don't have strong security concerns regarding your approach, since it mitigates the risk of attacks via application vulnerabilities by running the application as non-root. The fact that you run to container main process as root, I see as a minor disadvantage that only creates problems in niche access control setups, where not fully trusted subjects get read-only access to your system.
Should I run things inside a docker container as non root for safety?
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 capabilities during container startup, it is still the recommended approach to avoid being root
.
Usually it is a good idea to use the USER
directive in your Dockerfile after you install some general packages/libraries. In other words - after the operations that require root
privileges. Installing sudo
in a production service image is a mistake, unless you have a really good reason for it. In most cases - you don't need it and it is more of a security issue. If you need permissions to access some particular files or directories in the image, then make sure that the user you specified in the Dockerfile can really access them (setting proper uid
, gid
and other options, depending on where you deploy your container). 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 set its gid
, disable its shell and password login, as it is going to be a 'service' user. The user also becomes owner of /var/log/$SERVICE_NAME
, assuming it will write to some files there. Now we have a lot smaller attack surface.
Switching users inside Docker image to a non-root user
You should not use su
in a dockerfile, however you should use the USER
instruction in the Dockerfile.
At each stage of the Dockerfile build, a new container is created so any change you make to the user will not persist on the next build stage.
For example:
RUN whoami
RUN su test
RUN whoami
This would never say the user would be test
as a new container is spawned on the 2nd whoami. The output would be root on both (unless of course you run USER beforehand).
If however you do:
RUN whoami
USER test
RUN whoami
You should see root
then test
.
Alternatively you can run a command as a different user with sudo with something like
sudo -u test whoami
But it seems better to use the official supported instruction.
How to run ENTRYPOINT as root and switch to non-root to run CMD using gosu?
The code passed no arguments to the script. Imagine it like this:
bash -c '/app/startup-ssh.sh <NO ARGUMENTS HERE>' ignored ignored2 ignored3...
Test:
bash -c 'echo' 1
bash -c 'echo' 1 2
bash -c 'echo $0' 1 2 3
bash -c 'echo $1' 1 2 3
bash -c 'echo "$@"' 1 2 3
You want:
ENTRYPOINT ["/bin/bash", "-c", "/app/startup-ssh.sh \"$@\"", "--"]
Or, why the explicit shell if the file has a shebang and is executable, really just:
ENTRYPOINT ["/app/startup-ssh.sh"]
Related Topics
Linux Umask for Sudo and Apache
Scale PDF to Add Border for Printing Full Size Pages
Change a String in a File with Sed
Create/Delete Users from Text File Using Bash Script
Autoconf Check for Program and Fail If Not Found
Installing Rpostgresql on Linux
Does There Exist Kernel Stack for Each Process
Replace Column If Equal to a Specific Value
Ec2 Instance Launched from Ami Not Reachable(Ssh) After Start/Stop or Reboot
How to Use Performance Counters Inside of The Kernel
Golang Os/Exec, Realtime Memory Usage
Bash Tries to Execute Commands in Heredoc
Path Issue After Compiling Curl
What Are The Lowest Possible Permissions for Typo3
What Does It Mean to Break User Space
Where Does Top Gets Real-Time Data