$ docker run -rm -it busybox shĤ drwxr-xr-x 19 root root 4096 Dec 18 07:55. Lets start out by using the official ‘busybox’ image to fire up a shell inside of a container. The ‘docker version’ command indicates I have: $ docker version What I am going to do may well not be something that any sane person would do, but it highlights the fact that when running as the ‘root’ user within a container, it is currently truly the ‘root’ user even when seen from outside of the container.įor this demonstration I am going to use Docker Toolbox on MacOS X. To do this I am going to rely on the use of volume mounting.
Root access via the file systemĪlthough I am sure people will suggest this is a contrived example with limited application to only certain Docker installation types, I am going to show one example where running as ‘root’ in the Docker container can lead to being able to compromise the host that the Docker service is running on. In the interim, but then even with that coming down the pipeline, it is still preferable to simply not require your application to run as ‘root’ inside of a Docker container. So when this becomes a part of Docker and regarded as stable, hosting services using Docker will be able to use that. This is where although within a container it will appear that an application runs as the ‘root’ user and with the privileges of ‘root’ within the container, when seen from outside of the container it will in reality be running as a non privileged user. This is coming in the form of support for user namespaces. It is recognised as a big enough issue that I believe there are changes in train for the introduction of new features in Docker to reduce the risk. This is the case with OpenShift 3, but as similar services around Docker seek to limit their exposure to the risk of running as the ‘root’ user, even though inside of a container, you can expect them to do the same. It is therefore better now to start designing your Docker images so that they can be run as a non ‘root’ user.Įven now some hosting services based around Docker are restricting applications running inside of a Docker container from running as the ‘root’ user and forcing them to run as a non privileged user. This will no doubt change over time and be seen more importantly as a best practice to follow. If for some reason, be it a bug in Docker or the operating system itself, a misconfigured Docker installation or even that incorrect access rights were granted to some resource when running a specific container, running as ‘root’ is going to increase the risk of an application being able to access outside of the container, directly or indirectly, with elevated privileges.Īlthough there is a minor note in the Docker best practices guide about not running as ‘root’, it doesn’t get emphasised enough. Yes it can be argued that the application is isolated within a container and shouldn’t be able to break out, but it is still running with the privileges of ‘root’ regardless. Yet when we run applications inside of a Docker container, most people seem to have no qualms at all about running everything as the ‘root’ user. Not running applications as the ‘root’ user is viewed as being a best security practice. When we run any applications directly on our own computers we avoid doing so as the ‘root’ user unless absolutely necessary.
0 kommentar(er)
