Hi @oussjarrousse

This is a very interesting question, thanks for asking it. I'm no Docker security expert but I'll try to answer as best as I can.

Short answer

What do you recommend here ?

• running nginx-proxy in the separate containers setup, where the Docker daemon socket is mounted in a separate container that do not expose anything to the outside world.
• additionally, exposing the Docker daemon socket to the docker-gen container on an TLS protected endpoint rather than using the daemon socket. docker-gen supports it (see the DOCKER_HOST / DOCKER_CERT_PATH environment variables). Unfortunately, acme-companion does not (yet, but I'll look into this soon).

Maybe it makes sense to add a discussion about the associated risks to the documentation.

I completely agree. traefik is in the exact same situation and I quite like their documentation about this. And, like traefik, nginx-proxy can't work without access to the Docker daemon API in one form or in another.

More detailed answer

Why does nginx-proxy (more specifically docker-gen) need access to the Docker daemon ?

• to get the system infos from the Docker server.
• to listen (and react) to the system events happening on the Docker server.
• to get the list of containers on the Docker server, the list of networks, and the details for each container, from which it will render our nginx reverse proxying configuration.
• when nginx and docker-gen run in separate containers, to send a POSIX SIGHUP signal to the nginx container when we need the nginx process to reload its config.

As you can see all of those save one are just reading stuff, so what if we could just simply restrict permissions on the Docker daemon socket ?

Well, no we can't, not simply anyway:

Docker's out-of-the-box authorization model is all or nothing. Any user with permission to access the Docker daemon can run any Docker client command. The same is true for callers using Docker's Engine API to contact the daemon. If you require greater access control, you can create authorization plugins and add them to your Docker daemon configuration.

Creating or using Docker authorization plugins is a topic way, way outside the scope of this repository.

So what could we do without taking Docker authorization plugins route ?

1. ensure that the process that have access to the Docker daemon socket is isolated in its own container that does not expose anything to the outside world. That's the separate container setup.
2. secure the access to the Docker daemon socket. There is two way to do this, SSH and TLS. Unfortunately for SSH, docker-gen was created before Docker had an official Go SDK and so had to rely on another project available at that time, fsouza/go-dockerclient. TLS support is available with it, but SSH isn't and understandably won't. Re-writing docker-gen to use the official Docker Go SDK isn't out of the table, but that's a big project.
3. use tecnativa/docker-socket-proxy, the only way that I'm currently aware of to easily control what your service can and cannot do with the Docker API.

Regarding the second point (securing the Docker daemon socket with SSH or TLS) that OWASP insist on : it's not clear to me what difference that would make if the container that have access to the secured endpoint is compromised. AFAIK, if you gain access to this container you also gain access to the SHH or TLS credentials and then to the endpoint, exactly as if the Docker socket was directly mounted to the container. 🤔

I think that 1) and 3) are the most immediately important, followed by 2), but again I'm no Docker security expert.