My problem with Docker is that although the advise was always not to run images with root, in practice all Docker tools defaults to do precisely that and there are no plans to change the defaults.
At least these days they do provide options to restrict containers so secure usage is possible (--cap-drop=all is a good start), but still the amount of efforts to follow good security practices is high.
Yes, this has been my experience as well. It's either add your user to the docker group (which makes it equivalent to a root account) or run everything docker related with sudo. Your best bet is to run docker in it's own virtual machine which is somewhat ironic.
With 1.10 you can just enable User namespaces, which allows for root in a container to map to a non-privileged user outside the container, that way it's a one-time (per instance) change.
While this is a nice security boost once you're in the container, don't you still need to be root (docker group) in order to start the container? It honestly doesn't help me much if I have to give users root in order to start a container, even if they are wrapped inside the container.
Yep, at the moment, with raw docker engine, if a user has access to create containers, they're basically able to get root on the box, as the docker daemon runs as root and there isn't any authorization control by default, so it doesn't work well for that kind of scenario.
With that said there's a couple of ways this is getting addressed.
1) in 1.10 authorization plugins landed as a feature,so it's possible to add this functionality. 2) there's a number of services which run on top of Docker Engine (e.g. Docker Universal Control Plane) which have authentication/authorisation at that level.
Re:Docker and Security [pdf]
by cuckcuckspruce on Thursday March 10, 2016 @10:02AM
(#11259545)
This is what sudo is for. Give each user access to run their containers (and only their containers) as a member of the docker group in sudoers.
This doesn't work when users may need to run arbitrary (or user-defined) containers. You can only sudo so much... But, perhaps you could restrict it to "sudo docker run". I'll have to give that a try. But that would make it extraordinarily more difficult for a user to stop / rm / kill a container. Plus, it's not like docker has the concept of an "owner" for a container - does it?
Nonetheless, you shouldn't need to run anything as root in order to start a container that doesn't require extra privileges .
Please clarify what you mean by "access to run ... only their containers". How is that possible?
For example, as Docker can by default mount anything that root can mount, running
will give you complete root access to your file system in the docker container (the talk mentions some Docker features that will mitigate this kind of attacks, notably UID mapping). Of course no one would willingly do that, but if you mount user resources into your containers and the resource name contains something that an external user might control (e.g. his/her username), then injection attacks become possible. Even with UID mapping enabled this can leak sensitive information about your host system into the container. And since people often use containers to run untrusted code (e.g. for CI systems), this can be a large security threat in my opinion.Personally I really like Docker and I think it (or similar technologies) will change many aspects of IT/Devops/Data Analysis in the future, I just think that maybe they should have some more sensible defaults for security-relevant settings, i.e. only grant network access to containers if you ask for it, restrict default memory usage by default, limit the type of volumes you can mount, etc.