Is it possible to limit docker daemon to only buiding images (and not running containers)?


I am using Docker in Docker (dind) with --privileged flag in my CI to build images out of source code. I only need build, tag, pull, and push commands and want to avoid all other commands such as run (considered as root of all security problems).

  • Docker-Composer exited with code 0
  • How to change the docker terminal launch script?
  • setup drone continuous integration with github
  • How to move Docker containers to AWS
  • Setting .htcaccess in an external volume for Docker not working
  • Docker start a fresh instance(without the user data) of a stopped/running docker container.
  • Note: I just want to restrict Docker’s remote API and not the daemon itself!

    My best options so far:

    As Docker clients communicate with dind over HTTP (and not socket), I thought I could put a proxy before dind host and filter all the paths (e.g. POST /containers/create) to limit API access only to building/pushing images.

    What I want to avoid:

    I would never ever bind mount the docker socket on the host machine!


    It seems that the API routers are hardcoded in Docker daemon.

    Update 2:

    I went with my best option so far and configured an nginx server which blocks specific paths (e.g. /containers). This works fine for building images as it is done in the dind image and my API restrictions doesn’t screw the build process.

    HOWEVER: this looks really ugly!

  • change PATH for building docker image
  • fuser returns Cannot Permission denied
  • docker stucks when executing time.sleep(1) in a python loop
  • How to use docker-machine on a private server?
  • Docker swarm security and high availability on AWS
  • WordPress site url issues when using local docker container
  • 2 Solutions collect form web for “Is it possible to limit docker daemon to only buiding images (and not running containers)?”

    Docker itself doesn’t provide any low level security on the API. It’s basically an on or off switch. You have access to the entire thing, or not.

    Securing API endpoints would require modifying Docker to include authentication and authorisation at a lower granularity or, as you suggested, adding an API proxy in between that implements your security requirements.

    Something you might want to look at is Osprey from Mulesoft. It can generate API middleware including authentication mechanisms from a simple RAML definition. I think you can get away with documenting just the components you want to allow through…

    #%RAML 0.8
    title: Yan Foto Docker API
    version: v1
    baseUri: https://dind/{version}
      - token_auth:
          type: x-my-token
    securedBy: [token_auth]
          dockerfile: string
          t: string
          nocache: string
          buildargs: string
              tag: string

    Osprey produces the API middleware for you controlling everything, then you proxy anything that gets through the middleware to Docker.

    You could use OAuth 2.0 scopes if you want to get fancy with permissions.

    The docker client is a bit dumb when it comes to auth, but you can attach custom http headers to each requests which could include a key. config.json can configure HttpHeaders.

    From a theoretical perspective, I believe the answer is no. When you build an image, many of the build steps will create and run a container with your requested command. So if you manage to disable running containers, the side effect of that should be to also disable building images. That said, if you protect access to running docker commands from a trusted user, and that user builds an untrusted Dockerfile, that result of that build should be isolated to the container as long as you aren’t removing container protections with various CLI options.

    Edit: I haven’t had the time to play with it myself, but twist lock may provide the functionality you need without creating and relying on an api proxy.

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