docker-socket-proxy icon indicating copy to clipboard operation
docker-socket-proxy copied to clipboard

[Q] Does a docker socket proxy improve security?

Open lonix1 opened this issue 1 year ago • 5 comments

Originally posted at StackExchange and the docker forums.

I am using this docker image and think it's great, so please don't get offended by my question... I'm not trolling, I am very interested in this topic. Also note that this image has very high visibility because major apps (like Traefik) recommend it. So many people would be interested in this 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 that would abuse the docker socket, there could be malicious code inside Tecnativa that would abuse the docker socket.

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?

lonix1 avatar Jun 02 '23 11:06 lonix1

Just as there could be malicious code inside Traefik that would abuse the docker socket, there could be malicious code inside Tecnativa that would abuse the docker socket.

That's no the attack vector and very unlikely. The problem with exposing the socket inside of Traefik is that if it has a RCE or it could be tricked to redirect the request to the proxy, you have a privilege escalation. Having the proxy in between first of all filters the requests only allowing read operations for an application like Traefik and now you not only need to trick Traefik with a forged request but also the haproxy, too which is much more involved. Also if there are multiple containers needing access to the socket, it only gets mounted to one container.

SuperSandro2000 avatar Jun 02 '23 11:06 SuperSandro2000

I have significantly less knowledge of this topic than you, so firstly thank you, and secondly please excuse me for oversimplifying.

In my limited understanding, there is "a risk" of letting Traefik (or Portainer, or ...) access the socket. So we place a proxying mechanism in between them. But "some risk" could exist in the proxy itself.

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

Given that this is a standard way to solve this problem, and so many people are using it (10M+ downloads on docker hub), the risk factor is low (an exploit would be detected quickly). But it's not a "solution", it's just shifting risk around.

Not sure if I've explained myself properly... hope that make sense. Please educate me if I'm misunderstanding!

lonix1 avatar Jun 02 '23 12:06 lonix1

But "some risk" could exist in the proxy itself.

yeah, sure but worse case there is no improvement at all. It can't get any worse than a complete open socket.

and so many people are using it

that download count is highly inflated. I have myself images with 100k downloads which are definitely not that popular.

SuperSandro2000 avatar Jun 04 '23 22:06 SuperSandro2000

Thanks Sandro for your advice.

that download count is highly inflated. I have myself images with 100k downloads which are definitely not that popular.

I knew it! I always suspected those numbers are not real, especially for those 1B+ containers.

lonix1 avatar Jun 05 '23 00:06 lonix1