Does a docker socket proxy improve security?

Question

It's dangerous to expose the docker socket to a container, as malicious code could break out into the host. There are various ways to avoid this; a simple/popular approach is to use a proxy between the container and the docker daemon, which filters naughty requests. (The most widely used is Tecnativa Docker Socket Proxy.)

But surely that just moves the risk from the operational container (e.g. Traefik or Portainer, which need access to the docker API) to the socket-proxying container (e.g. Tecnativa)? Just as there could be malicious code inside Traefik/Portainer/whatever that would abuse the docker socket, there could be malicious code inside Tecnativa that would abuse the docker socket.

So ultimately, it's a choice between me trusting the Traefik/Portainer/whatever image (and its authors), or trusting the proxy image (and its authors).

One could even make the argument that it's more sensible to trust Traefik / Portainer (which have huge user bases, and large numbers of developers) to a docker socket proxy. (In other cases, of random never-heard-of container images that wants docker socket access, I'd obviously trust the socket proxy more.)

Is this an example of copy-and-paste-blog-advice, or is there more to it that I don't understand?

Answer 1

A docker proxy is a layer of defense, which restricts the interaction between a potentially harmful system (running inside docker) with a critical environment (the docker host). By limiting the interaction it limits the attacks which are possible against the docker host from an intentionally malicious docket guest, but also from an insecure one which was compromised.

It serves a similar role like a sandbox around a potentially harmful application, i.e. basically anything which processes external untrusted input and might have bugs. Therefore such sandbox technologies are used for example to restrict how critical parts of a browser engine can interact with the host system.

It also serves a similar role to a firewall which restricts the interactions of a potentially harmful IoT device (SmartTV, light bulbs, DVR, ...) with the network where it is used, i.e. deter any attacks of a potentially compromised device against other systems inside the network.

It is true, that such firewall, sandbox or docker proxy have a trusted role in these environments and that they might be used to attack instead of protecting the environment. Thus, it is important to use only components here which are sufficiently trusted, i.e. at least significantly more trusted than what they should protect from.

Part of this trust comes from the design of these protection layers: they have a clearly defined role and the implementation of this role is comparatively simple and thus critical bugs are less likely. Having something open source or at least vendor-independent audits adds to the trust. Of course, if you suspect that the author of the protection layer intends to harm you, then you should not use it.

Answer 2

Like so many things in security, this depends on your threat model. where something like this could be useful is, say you give users access to portainer/traefik/whatever else has Docker socket access.

You want to allow them to carry out some Docker commands, but not others. This is tricky in the standard Docker security model as generally once someone has Docker access they can carry out any Docker command.

So you as the sysadmin could setup this proxy to restrict what users of the application can do via Docker.

It could be tricky to lock things down this way, but might be a good option in some circumstances.