sudo access to socket
ambsw-technology opened this issue · 3 comments
I'd like to use sudo to access the docker socket rather than the docker group. I'm happy to contribute a patch but want to make sure it's (1) compatible with the way docker-fabric already does things and (2) something that would be accepted once it was working. Any hint on the right part of the architecture to explore would also be much appreciated.
We got to this point because we wanted to use our LDAP to control who has docker access. We already control sudoers using LDAP groups and this article was the "duh" moment that we could do the same for docker with a specialzed sudoers line (and make it all transparent to our users). As a HIPAA-compliant organization, the security benefits that motivated the original article made it a "must have" for us.
Unfortunately, docker-fabric fails in this configuration and we want to fix it.
Thank you for sharing the article. Unfortunately docker-fabric would not work with this, since just like the docker command line client it requires access to the socket. Therefore docker-fabric would have to generate command line strings rather than communicating with the API directly. I am currently refactoring parts of the underlying library Docker-Map which would technically also make this easier, but it would require some more work in order to get all options transformed correctly.
In docker-fabric, socat handles the redirection of the client to the socket. Therefore, if it is just about knowing when Docker is run, socat (or an alias thereof) could be prefixed with sudo. That would be easy to implement). However, that would not expose to the system logs which containers are being run and in which configuration. So in the sense of the article, it is not sufficient.
If the idea is to restrict management to a set of managed containers, I would suggest implementing a script based on Docker-Map that either cannot be modified or simply disallows setting the privileged flag by checking configuration and keyword arguments before creating a container. That script and its configuration would have to be installed directly on the server, but could be invoked via Fabric.
The goal is the audit logs... not restricting container access.
I also realized that I closed this issue too soon since a full solution requires a change to the way commands are piped to the client... which is all handled in this project.
If you like my suggested strategy in docker-map, we'd still need a way to get those commands to run on the remote machine. I'm thinking we could write the docker CLI module with a "call" method that basically shadows subprocess.call. docker-fabric need only overload that method with an appropriate fabric command (e.g. run or sudo).
Implemented in release 0.4.0.