We are setting up a Ubuntu machine for developers as a “playground” for learning Docker, and for testing out new images before they are put into production. (Most of our desktop PCs run Windows, so this is to provide a native *nix Docker environment.)
By default, a container runs with root privileges within the container. Inside the container, abusing those privileges that doesn’t hurt anyone but the user starting it - the next user of the same image will run a virgin container, unaffected by any other run. The user may at container startup mount a volume containing his input files, and ready to receive his output files. (This is our standard working mode.) A malicious user could destroy or otherwise affect the files in the volume that the user has provided himself. Why would he?
But… The user may mount / - the root directory. The container code may access the entire file system with root privileges. If a shell is provided (e.g. in the Ubuntu base image), you can start the container with the -it options and broswe the entire file system manually, unrestruicted by access limitations. Sure, the root privileges outside the container is restricted to what you can do by file system operations - but in *nix, that is quite a lot!
Those running Linux on their desktops have sudo access to that machine, so whatever malice they can do from a Docker container, they can do by sudo - but it affects only their own, private desktop. It is different on a shared, central Playground machine - they could create havoc for other users, and they could gain access to e.g. NDA-protected code of other projects that are doing tests in the same sandbox.
Fortunately, we do not have many developer with malicious intentions Yet, I suspect that a security audit may be critical to this, considering that the playground is a resource shared by all sorts of projects.
Is there any way to keep developers from creating containers running with root privileges? Or any way to prevent users from mounting volumes with files they do not have access to (or rather: filter the container’s access to the volume by the rights of the running user), in a way that cannot be circumvented by the users?
Production images create no problems: They always define a non-root user. But as long as we let developers build their own images, we see a certain security risk. We more or less “must” allow our developers create new test versions of images!