![docker run as root override user docker run as root override user](https://res.cloudinary.com/practicaldev/image/fetch/s--i0P5xmbv--/c_imagga_scale,f_auto,fl_progressive,h_900,q_auto,w_1600/https://dev-to-uploads.s3.amazonaws.com/i/3tkf67mcgduyeozbvjzp.png)
The value of the ‘USER’ statement must be the integer UNIX user ID of the UNIX account you want any application to run as inside of the container. This should be done by adding the ‘USER’ statement in the Dockerfile. Always override in the Dockerfile what user the image will run as. What then is a better guideline about what user a Docker-formatted container should be run? I would suggest the following.ĭo not run a Docker-formatted container image as the root user. Even if the supplier of the image had still fiddled with the passwd file it wouldn’t matter, they can’t change the fact it will run as that user ID. Thus by requiring that ‘USER’ be set to a UNIX user ID, we are able to guarantee that it will run as the user it says it is. bashrcĤ -rw-r-r- 1 root root 177 Dec 1 05:10 Dockerfile Run the image and we get: $ docker run -it -rm best-practicesĤ drwxr-xr-x 28 root root 4096 Dec 1 05:12. That this is the case, can be validated by inspecting the meta data of the Docker-formatted image using the ‘docker inspect’ command: $ docker inspect -format='' best-practices We can see that this was the last statement in the Dockerfile, and so this should be what user is used when the image is run. This is what declares what user the container should run as. The problem is the ‘USER’ statement added to the Dockerfile. Seems simple enough, so why is this a problem? Who do you think you can trust? If we build and then run this image and have it start up an interactive shell, we can validate that the command we have run is running as the user ‘app’ and that we are in the correct directory. Skeleton for a Dockerfileįollowing the above guidelines, the skeleton for the Dockerfile would look like: FROM centos:centos7 RUN groupadd -gid 1001 app RUN useradd -uid 1001 -gid app -home /app app COPY. At the end of the posts I will summarise what I believe are a better set of basic guidelines around setting up a Docker-formatted container image. In subsequent posts I will pull apart the other guidelines. In this blog post I am going to look at the last guideline in that list, and issues around how you specify what user an image should run as. Unfortunately there are still a number of problems with these guidelines, as well as things that are missing. Set the user that the image will run as to the ‘app’ user.Īll looks good, and better than running as the root user you might be thinking.
![docker run as root override user docker run as root override user](https://i.ytimg.com/vi/yHytb1k3TfM/maxresdefault.jpg)
DOCKER RUN AS ROOT OVERRIDE USER CODE
Put all your application source code under the ‘/app’ directory.Create a new UNIX account with user name ‘app’ with a user ID (uid) of 1001, with it being a member of the group ‘app’ and where the home directory of this user is the directory ‘/app’.Create a new UNIX group called ‘app’ with a group ID (gid) of 1001.As such, organisations are for their own images at least, starting to create basic guidelines for their developers to follow around what user an image should run as.Ī typical example of the most basic guidelines you can find are: With more and more organisations moving towards containers and using these images in production, some at least are realising that running them as root is probably not a good idea after all. If you follow this blog and my rants on Twitter you will know that I often complain about the prevalence of Docker-formatted container images that will only work if run as the root user, even though there is no technical reason to run them as root.