You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
andrun
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:The entrypoint creating this user looks like:
Neat. Classy. 😎
The text was updated successfully, but these errors were encountered: