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?

  • Also posted at the docker forums and that proxy image's repo.
    – lonix
    Jun 2, 2023 at 23:34

2 Answers 2


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.

  • 1
    Thanks. This enforces my view that most blogs (and questions on StackExchange) which promote a socket proxy (or this one in particular) are simply copy-pasting what others have written, without thinking. It improves security in theory, but one must be mindful that the proxy itself could have malware. And to reiterate what I wrote above, I trust Traefik (1B downloads) more than Tecnativa (10M downloads). That said, I do use it myself, so I'm a hypocrite. :-)
    – lonix
    Jun 3, 2023 at 14:35

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.

  • Thanks Rory, you are right this depends on one's tolerance for risk. I think it's "a solution" rather than "the solution". But others portray it as the former, which is misleading.
    – lonix
    Jun 3, 2023 at 14:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .