DEV Community

Cover image for Docker Best Practices: Images

Docker Best Practices: Images

Grigor Khachatryan on November 20, 2018

Understand build context When you issue a docker build command, the current working directory is called the build context. To exclude fi...
Collapse
 
alex_barashkov profile image
Alex Barashkov

I see the recommendation of non root user not a first time, but still haven't seen just a real example when it's actually could harm. Also if Google dockerfile examples for production it seems almost everyone do not create a new user for running an app. Would be happy to finally find out what the case we need to scare about?

Collapse
 
grigorkh profile image
Grigor Khachatryan

There's really no issue... so long as you run the container unprivileged, and totally isolated from the host. Because you can't guarantee how containers based on your image will be run, however, it's important to assume it will be run privileged, or not 100% isolated. If process within a container is running as root, they'll have unrestricted access to each of these egress to the host and could give you problems if compromised.

And you may say that you'd have to be a total noob to run a container wrong. But it's actually pretty easy to run a container sorta privileged:

  • Mounting any volumes from the host? Anything with root access in the container will now be able to create, delete, or modify files with any UID or GID in that volume directory.

  • Binding a privileged port on the host to a port (even privileged) in the container? Any root process in the container can now listen on that privileged port on the host. This could allow folks to turn your host into an official-looking server by compromising the root processes in the container.

  • Mounting in the docker socket? Any root process in the container can now control the docker daemon on the host. This means a compromised process can start 100% privledged containers with the host's root directory mounted in as a volume.

  • Imagine a Linux kernel user namespace bug that could only be exploited if the namespace user is root. Hypervisor escapes are a real thing. Namespace escapes will be too. See for example:
    lkml.org/lkml/2013/3/4/70
    "It'll abuse the above request_module() call to load any module the user requests -- iregardless of being contained in a user ns or not."

...and the list goes on.

But it all comes down to someone running a container in a way that's not isolated from the host. As long as you can guarantee that that will never happen, and barring bugs in Linux Containers, you are good to run root processes in Docker containers.

More ref:
gist.github.com/FrankSpierings/5c7...

security.stackexchange.com/questio...

Collapse
 
alex_barashkov profile image
Alex Barashkov

Great response, thanks a lot for that extensive explanation. Now I see that in my case I should not worry about it.

Collapse
 
grigorkh profile image
Grigor Khachatryan

Nice tool. Will take a look. Thanks!