Purpose
It is commonly assumed to be a good practice to avoid using the root user or any other privileged user to run an application in Docker containers. Moreover, when working on a dockerized project like Fonzie, we need to mount host volumes containing at least the sources of our application and temporary assets. In this condition, building the container (using a privileged user) can create files with high level permissions on the host system.
To prevent this last situation, we have wrapped docker build and run commands to use the local user/group ID in our containers. The counterpart of this is that our containers are system-specific and won't work anywhere else. For now, there is no big deal with this as long as our container will not get distributed or used anywhere else than on each developer's machine.
But this can appear as a complex implementation as things can get simpler following OpenShift guidelines.
Proposal
In our Dockerfile, give the container's user permission to write in the /etc/passwd file, create a user (that will run our container) with a random user ID, and define an entrypoint that will create a new user mapping the host user with the container user:
RUN chmod g=u /etc/passwd
ENTRYPOINT [ "uid_entrypoint" ]
USER 1001
The entrypoint creating this user looks like:
if ! whoami &> /dev/null; then
if [ -w /etc/passwd ]; then
echo "${USER_NAME:-default}:x:$(id -u):0:${USER_NAME:-default} user:${HOME}:/sbin/nologin" >> /etc/passwd
fi
fi
Neat. Classy. 😎
Purpose
It is commonly assumed to be a good practice to avoid using the
rootuser or any other privileged user to run an application in Docker containers. Moreover, when working on a dockerized project like Fonzie, we need to mount host volumes containing at least the sources of our application and temporary assets. In this condition, building the container (using a privileged user) can create files with high level permissions on the host system.To prevent this last situation, we have wrapped docker
buildandruncommands to use the local user/group ID in our containers. The counterpart of this is that our containers are system-specific and won't work anywhere else. For now, there is no big deal with this as long as our container will not get distributed or used anywhere else than on each developer's machine.But this can appear as a complex implementation as things can get simpler following OpenShift guidelines.
Proposal
In our
Dockerfile, give the container's user permission to write in the/etc/passwdfile, create a user (that will run our container) with a random user ID, and define an entrypoint that will create a new user mapping the host user with the container user:The entrypoint creating this user looks like:
Neat. Classy. 😎