What is the Docker security risk of /var/run/docker.sock?

In this blog article, I found the quote below in a comment:

Ben Firshman

  • Why doesn't a command that works inside a docker container work from outside via docker run?
  • docker: Dockerising multiple wordpress sites
  • Where should environment-specific values be saved in a Laravel 5 application?
  • Docker: Looks something went wrong in step Looking for vboxmanage.exe
  • fio: blocksize too large for data set
  • Docker push - net/http: TLS handshake timeout
  • Yes – you’re right I should have pointed out the security issue with the Docker socket. That’s currently the main blocker to this being practical in production and we’re definitely looking for help to make it work better, as you noticed from the to-do list.

    While I am sure this made sense to many, for the rest of us, could someone explain in clear terminology exactly what this “security issue” is? I assume it refers to:

        volumes:
      - "/var/run/docker.sock:/var/run/docker.sock"
    

    in the docker-compose file. Is that correct? How would this be exploited? Does this effectively prohibit this approach from Production usage? If so, is there a workaround?

  • I can't access to kafka broker outside docker container
  • How to import a CSV inside a Docker container with Java 8?
  • Get 502 Bad Gateway when use fastcgi_pass: 127.0.0.1:9000
  • managing multiple mesos marathon json configurations for deployment
  • Installing Docker with sudo
  • Docker deployments fail on Marathon, work fine otherwise
  • 2 Solutions collect form web for “What is the Docker security risk of /var/run/docker.sock?”

    for the rest of us, could someone explain in clear terminology exactly what this “security issue” is?

    The owner of the docker /var/run/docker.sock is root of the host where the container is running, with default group membership to docker group. That’s why mounting var/run/docker.sock inside another container gives you root privileges since now you can do anything that a root user with group membership of docker can.

    Does this effectively prohibit this approach from Production usage? If so, is there a workaround?

    For a workaround may be these posts will help: https://integratedcode.us/2016/04/08/user-namespaces-sharing-the-docker-unix-socket/ and https://integratedcode.us/2016/04/20/sharing-the-docker-unix-socket-with-unprivileged-containers-redux/

    Taking a step back, it would be useful to understand the usecase where you need to mount var/run/docker.sock and see if there are alternative ways to satisfying the usecase. Unfortunately, without a usecase description in the question, it is difficult to provide an alternative which avoids mounting the unix socket.

    Good luck and kudos for trying to do the right thing!

    Any process that can write to the dockerd socket also effectively has root access on the host…
    Well, can you use that or not in production is up to you.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.