Re: [atomic-devel] Authentication/Roles Based Access Control with Docker API.

[Clayton Coleman <ccoleman redhat com>]

> On Nov 21, 2014, at 10:29 AM, Daniel J Walsh <dwalsh redhat com> wrote:
> 
> I have begun thinking about securing the docker socket, and I wanted to
> open a discussion on this
> to get other peoples ideas.
> 
> Docker currently uses group permissions to control who can connect to
> the docker socket. 
> If you have the docker daemon listen on the network, then there is no
> security.  The ability to talk
> to the docker socket is the equivalent of giving the user root, which I
> blogged about here.
> 
> http://www.projectatomic.io/blog/2014/09/granting-rights-to-users-to-use-docker-in-fedora/
> 
> I believe we need to start working on fixing this. First I would like to
> see authentication fixed. 
> We need some mechanism to allow administrators to specify which users
> are able to manage docker?
> Then once you have this, you need to manage what they are allowed to do
> once they are connected to
> the daemon.
> 
> Can we have a read/only model, where a users or tool can just list the
> running containers
> 
> docker ps, docker images, docker inspect ...

How do we control which properties of images are considered secure (container env with passwords, images with embedded keys)?  

Who can run docker cp?

> 
> How do we control which users are able to start/stop docker containers?
> 
> Who is allowed to run/create a container on a specific image? 
> 
> Who is allowed to execute a container using privileged commands?
> 
> What is a privileged command?
> 
> --privileged  --security-opt --cap-add --cap-remove --net , --ipc ...
> 
> Do we want fine grained control of these options?
> 
> How can we do this without making it hopelessly complex?
> 

How do we make docker build secure?  Should docker build be able to run as a non-root user (the actual build steps)?  

How does an admin easily give a known user certain dangerous privileges (sudodocker)?