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

Rationale:

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).

  • WordPress on Docker: mysqld entered FATAL state, too many start retries too quickly
  • Access host IP inside docker container using docker-compose
  • How to share a value between all docker containers spun op by the same “docker-compose up” call?
  • Docker linking db container with spring boot and get environment variables
  • How to run Apache Spark 2.1 Driver Program in docker container with bridge mode
  • Generic Python Object Serialization for Docker Integration
  • 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!


    Update:

    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!

  • Difference between links and depends_on in docker_compose.yml
  • Docker Swarm - Map ports and Scaling
  • Proper handling of request_uri in double nginx reverse proxy?
  • What would the deploy.sh file look like for Gitlab CI?
  • Java application cannot get IP address of the host in docker container with static IP
  • Docker Compose stuck downloading or pulling fs layer
  • 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}
    
    securitySchemes:
      - token_auth:
          type: x-my-token
    
    securedBy: [token_auth]
    
    /build:
      post:
        queryParameters:
          dockerfile: string
          t: string
          nocache: string
          buildargs: string
    /images:
      /{name}:
        /tag:
          post:
            queryParameters:
              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.