It works with Docker swarm ?

[D0wn3r]

Do this works with docker swarm ?

I have a

level=WARN msg="blocked request" reason="forbidden IP" method=GET URL=/v1.24/version client=10.0.2.67:60802 response=403

When I try to use it with Traefik v3. I guess this is supposed to be allowed with the option -allowfrom=reverse-proxy in the command but with swarm is that works ?

(reverse-proxy in the name of my traefik service in the stack)

Thanks

[D0wn3r]

It works if I set ip (but I would like it dynamic) and if I allow all GET

services:
  dockerproxy:
    image: wollomatic/socket-proxy:1 # see https://github.com/wollomatic/socket-proxy for reference
    command:
      - '-loglevel=info' # set to debug for far more logging
      - '-allowfrom=10.0.2.67,10.0.2.68,10.0.2.62'
      - '-listenip=0.0.0.0'
      - '-allowGET=.*' # this regexp allows readonly access only for requests that traefik needs
      - '-shutdowngracetime=5'
      - '-watchdoginterval=600'
      - '-stoponwatchdog'

[wollomatic]

The above error message is caused by the -allowfrom configuration.

If the hostnames in Swarm are dynamically generated, it is difficult to set an allowlist for them. A possibility would be to allow a local network range, e.g., -allowfrom=10.0.2.0/24. Please keep in mind that this can easily result in insecure configurations (on the other hand, most of the other Socket-Proxy-Software allows access from any IP).

---

The -allowGET option depends on how you use Traefik:

If you use the docker provider (https://doc.traefik.io/traefik/providers/docker/), the '-allowGET=/v1\..{1,2}/(version|containers/.*|events.*)' is fine for socket-proxy.

You probably need another configuration for the allowlist if you use the swarm provider (https://doc.traefik.io/traefik/providers/swarm/): Maybe -allowGET=.* is fine in that case. You can enable the debug logging and see how the requests look. After that, you can create a more specific working regexp.

Also, see #30

(I'll convert this issue to a discussion)

[D0wn3r]

So -allowfrom doesn't support swarm service name ?
It would be very cool to have this support.
What -allowfrom try to match exactly ?
How it works behind the scene maybe we can find a way to make it work with swarm mode

[wollomatic]

-allowfrom supports any hostname that is resolvable via DNS. So, if you have a static hostname, it will work with Swarm. The only way it does not work is when hostnames are dynamically created.

Socket-proxy resolves the hostname given with -allowfrom from the configured DNS server and compares whether any of the resolved IP addresses matches the IP address of the requesting client.

[SempleSituation]

I have this mostly working with Traefik in a Docker Swarm with one notable issue.

If I have a service that has to run globally and uses the docker socket, I cannot get this to reliably work (due to the dynamic naming limitation mentioned above I guess?)

The closest I have gotten is to run the proxy globally too, but there is no way for me to assure that a request resolving the proxy will pick the one local to the container that is is running on. Things like Portainer's agent, Dozzel, or other solutions that are attempting to get local socket information are limited.

I wonder if you could resolve this by providing an option to include a wildcard in naming? It has been a couple months since I played with it but I believe all Swarm services are resolvable via a known dynamic name like servicename.nodeid . Perhaps it would address this one issue that I think all socket proxies have that limit swarm users. Is this something that is possible for future consideration @wollomatic ? If so, is there a place I can log a feature enhancement.

Another idea I had a couple of weeks ago is if my socket network was always host only and not an overlay and swarm friendly network. Then I thought local services querying for a service locally would only see that one... I have not tested this though... it was a bedtime theory.

This gap has me struggling with some services.....

[wollomatic]

Hi @SempleSituation,
my idea ist to keep socket-proxy simple and stupid, but this is a good use case. I'll think about it.

[IGitYou]

@wollomatic Thanks for the consideration. I understand the desire to KiS and hope the request is not too complex. It currently seems to be a limitation of all the equiv solutions, with no real solution outside of "You are being too extreme in your security practices and do not need to proxy your socket" being the prevailing answer. The issues seem to manifest in the projects needing the socket, but now I see the root cause is the addressing of the socket. I had read the issue is "dynamic names" historically.

Thanks again for the consideration and if I should move this request to Ideas please let me know.