6

I am trying to make docker on a server more secure. The main problem is that most people say "if a person has access to docker, they can be root too" for an administrator point of few this is not something you would want.

To elaborate, they can use -v and mount /etc onto /mnt in the container and change the shadow file and gain access to the host. They can use -d, or privileged option to do more too.

So basically, there are a few things that i want to "try" and restrict.

  1. Volume bind mounts
  2. Privileged
  3. --add-cap
  4. -d (certain items?)

My ideas so far:

  • Alias to a bash script for docker, use sudo on it and regex all that they should not do.
  • Turn on remote api, secure it and perhaps reverse proxy it with nginx and regex in nginx the things they should not do.
  • Use other tools? Mesos/Marathon/Swarm/Shipyard/Whatever

Optional items would be to make containers on commit to git code, and let a "checker" verify the contents of the Dockerfile and create the image for them. Then sign that image and deploy it automatically. (but this would not give them much freedom anymore)

Also, removing the bind volume is not the nicest. Would be much simpler if we had a plugin for docker that says "you can only mount on /data, as user X" where the USER in the Dockerfile is that user X.

Something like docker-novolume-plugin is already a nice start for the volumes, doesn't restrict bind volumes though.

In the end the question would be, how can i let users build/pull/run docker images as their own user/docker and not be able to root the system. Doesn't have to be perfect as long as it works.

chicks
  • 3,639
  • 10
  • 26
  • 36
Erik-Jan Riemers
  • 235
  • 1
  • 2
  • 7

1 Answers1

5

Securing a docker engine requires paying attention to many different aspects, and defense in depth is always about layers of security.

One of the requirements you have listed, restricting what users can command the docker engine to do, is probably one of the most important, as, as of now, the docker engine does not implement an authorisation control.

Your alternatives include:

I would also suggest to look into the different operating systems a docker engine can be deployed to, and would advise not to use a general purpose OS but a specialised one, such as Atomic. Both, Atomic and OpenShift together, will ensure that you also can:

dawud
  • 14,918
  • 3
  • 41
  • 61
  • Nice writeup. Didn't know openshift/atomic, i'll look into that. The other items are more mitigations then 'holy grail' imho. Either way, maybe more people have some ideas (can't hurt) if not i'll accept this one. – Erik-Jan Riemers May 27 '16 at 22:43
  • Agree, as I said, security is about layers. SELinux, however, I'd argue it's central to have a secure docker server in production as of now. – dawud May 27 '16 at 22:45
  • We already use SELinux, so that is a good start. I did read things about user namespaces, that could possible have some help into restricting things too. (not having the same root uid) – Erik-Jan Riemers May 27 '16 at 23:06