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?
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.
That’s the wrong approach.
Have you found any malicious code? Simply stating the possibility, based on unwarranted paranoia, seems counterintuitive.
The more interesting question would be what you are doing that would justify this level of scrutiny.
Furthermore, the docker socket proxy leverages haproxy and at its core just configures the haproxy.cfg and then starts haproxy to filter out resource endpoint paths that should not be allowed.
The intention is to add an extra layer of security, by denying access to specific endpoints, so that in case a program that interacts with the daemon.sock get exploited, an attacker has not unrestricted access to the docker.sock.
If you want real security, you might want to enable certificated based user authentication, and use an authz plugin that allows to draft access rights using policies. I am not going to dive into this, as these topics have been discussed a couple of times in this forum already.
The “docker socket problem” has a large number of blog articles and StackExchange questions devoted to it, and the most common advice is to use a docker socket proxy (I mentioned a specific one, but there are others).
What concerns me is that it’s copy-paste advice and people don’t realise what they’re actually doing - I didn’t have a clue until I dug deeper into the topic. It’s portrayed as “the solution” but it’s actually “a solution”, and one just shifts trust from one tool to another, without solving the problem.
As mentioned above there are other approaches, so perhaps the real solution probably lies there. But the socket proxy is so quick and easy, so that’s what most would do (me too).