Sharing the Docker UNIX Socket with Unprivileged Containers: Redux

A few weeks ago I published a blog post discussing methods for sharing the Docker UNIX socket with unprivileged containers; for example when the Docker daemon has user namespaces enabled.

Brian Krebs made some useful comments about my assertion that a socat proxy in a privileged container, un-EXPOSEd to the host network, was one reasonable solution. Specifically, Brian showed how the container is most definitely accessible to other users on the host, given some rudimentary Linux skills for poking around to find the IP of the container in /proc file contents. Therefore, as I noted in my comment response it makes sense to show a more bulletproof example where we continue to provide Docker API access, but with limitations to prove that we could more securely share access without giving away the farm, so to speak.

Of course, my assumption so far is that commenter Brian Krebs is really the “krebsonsecurity.com” author, and not just some acne-challenged 17-year old named “Brian Krebs” from Surprise, Arizona who enjoys using his dad’s old laptop after school, on which he has hand-built and installed Gentoo Linux. We will continue with this assumption as it is much better for my street cred that the “real” Brian Krebs is commenting on my blog! [My lawyers asked me to include that “this blog post is no way infers or avows that the Gentoo Linux distribution, hereafter referred to as “Gentoo,” is merely a toy for pimply faced 17-year old basement hackers“]

So, with that aside, let’s take a look at a more complete solution for sharing the Docker API UNIX socket with unprivileged containers.  The general design I mentioned in a response to Brian includes using the new authorization plugin feature of the Docker engine joined to a more robust forwarder between HTTP -> UNIX socket that inserts a header to mark the API request as coming from an unprivileged user.

Authorization Plugin

The helpful guys at Twistlock contributed an authorization plugin framework to Docker, and it was merged into the 1.10 engine release back in February 2016. Additionally they have open sourced a policy-based plugin using this framework as an example for others to extend and use. For a simple implementation of the design idea mentioned above, I forked their plugin broker and added a second example implementation that uses an injected request header as the filter for approved actions for the Docker daemon API.

To test my new authorization plugin, I need to restart the Docker daemon and tell it I have an authz plugin. You can build the binary using the Makefile in the project above and run it on your Docker host as follows:

 $ sudo ./authz-broker --authz-handler=header \
                       --auditor=header

This will register the plugin in the appropriate location for Docker plugins (/run/docker/plugins), and then you may start the Docker daemon pointing to this plugin:

 $ sudo docker daemon --userns-remap=default \
        --authorization-plugin=authz-broker

I can watch the request/response streams from running Docker commands in the output of my authz-broker process and see that when using normal socket access (not via the forwarder I’m about to set up) I see it uses the codepath in my authorization code that allows any/all API access:

{"allow":     true,
 "err":       "",
 "fields.msg":"action 'docker_info' allowed; all privileges OK",
 "level":     "info",
 "method":    "GET",
 "msg":       "Request",
 "time":      "2016-04-20T10:43:49-04:00",
 "uri":       "/v1.23/info",
 "user":      ""}

Now that I’ve proven my authorization plugin is actually inserted into the API request flow, let’s set up the forwarder that will insert our special header.

Nginx-based Proxy

To make things simpler I’ve moved away from socat in this more advanced example because it turns out it is just dead simple to use a small nginx proxy to do this extra header insertion. As an added level of detail, remember that socat is at its essence just a packet copier, and we now have work we want to do at the HTTP layer. So, sure, I’m wimpy to escape to the ease of HTTP layer tools, but it really makes this example much simpler.

I’ve created a GitHub project with a Dockerfile which starts from the DockerHub hosted nginx image (I’m using the alpine-based one for a nice small image), and adds an extremely simple proxy/forwarder. Note that I have added the nginx user to the docker group, which I know on my host is gid 999; without this addition, the nginx proxy will not have read/write access to the mounted docker UNIX socket. This configuration enables functionality that is an exact copy of our socat worker from the prior post. The only additional work it is doing is adding our special header as it proxies the traffic along:

#server config
server {
    listen 2375;

    location / {
        proxy_pass http://unix:/var/run/docker.sock:;
        proxy_set_header X-Docker-Unprivileged true;
    }
}

We can then run this forwarder as we did our socat container in the last post: as a privileged container with the Docker socket mounted:

$ docker run --privileged --userns=host \
    -v /var/run/docker.sock:/var/run/docker.sock \
    unprivsockfwd

Now we can test our forwarder from an unprivileged container and see if our requests for anything other than ‘read’ APIs are blocked:

$ docker run -ti --rm --link unprivsockfwd:unpriv ubuntu bash
root@b8748db90c09:/# curl http://unpriv:2375/version
{"Version":"1.11.0","ApiVersion":"1.23","GitCommit":"4dc5990","GoVersion":"go1.5.4","Os":"linux","Arch":"amd64","KernelVersion":"4.2.0-35-generic","BuildTime":"2016-04-13T18:38:59.968579007+00:00"}
root@b8748db90c09:/# curl -X POST http://unpriv:2375/containers/create
authorization denied by plugin authz-broker: action 'container_create' not allowed due to unprivileged API access header
root@b8748db90c09:/#

It looks like our authorization plugin is doing what we asked it to do! For any simple HTTP GET API request we get the valid response from the Docker API, but if we try HTTP POST requests (like the container create API), we receive the disallowed response from our authz plugin given we only have unprivileged API access. Using this simple starting point, you could create a much richer set of API filtering depending on your specific allowance for unprivileged access to the Docker API. For example, given you receive the entire request detail, you could create a filter which allows only non-privileged containers to be created which request no volume mounts from the host.

Hopefully this provides a more secure method by which the Docker UNIX socket can be shared with unprivileged containers. I’ll be waiting with bated breath for responses from either of the Brian Krebs. :)