FR: Support granular API permissions on a per host basis via allowfrom

[nathang21]

Describe the feature request
Naturally many services require access to the docket socket, and while socket proxy is an excellent solution, to achieve minimal permissions for each each service would require a seperate sidecar for each. Multiple hostname support in #15 is great, but they all have to share the same permissions. While socket-proxy is very lightweight, i'm not a huge fan of running this many sidecar containers in general.

In my case I have 8 services, and would need 8 sidecars, some of these are read-only, while others also write. If interested, here are the 8 I use now:
ofelia, dozzle, watchtower, autoheal, beszel, boinc, dockwatch, portainer.

I realize supporting this would add complexity, but my ideal solution would be to have allow a separate configuration for each rest API Method on a per host (ip/hostname) basis. I suspect adjusting the configuration via environment variables or an configuration file would be required to make this maintainable.

I could imagine something like this:

allowfrom:
  - dozzle:
      allowGET=
  - ofelia:
      allowGET=
      allowPOST=
      allowDELETE=
...

Are you open to supporting this use case?

[wollomatic]

Hi @nathang21,

thanks for Your suggestion. Indeed, using one instance of socket-proxy for multiple services is a popular topic.

A yaml file would allow configuring this without breaking existing installations. Just give me a few days :)

Also, thanks for the list of the services you'd like to use. I only get to know how others use socket-proxy through feedback. So this is very important to me.

[nathang21]

Fantastic, thanks for the quick turnaround. Happy to help test when the time comes if needed.

If it helps, I'm also considering to add this soon, which has a native docker service discovery integration that requires the socket as well. https://github.com/gethomepage/homepage

[wollomatic]

Thanks for the additional information. BTW, I tested homepage by myself because of a question here: gethomepage/homepage#3266 (reply in thread)

[nathang21]

Thanks for sharing the homepage requirements!

Just wanted to check back in, looking forward to harding my services with this.

[wollomatic]

Sorry for the delayed answer. I plan to get it done this month.

[Marshalldeluna]

Any chance this could still be added
I would prefer to run just 1 instance of the socket-proxy

[wollomatic]

Well, it seems to be a very long month, but yes

[chrishoage]

Since this project by its very nature requires access to the raw socket exposed by Docker it could be interesting to instead use a similar approach to Traefik and use labels to control configuration.

One could imagine a label or set of labels applied to a service that could be read by socket-proxy.

These labels would inform socket-proxy as to what containers should be allowed which requests. By extension if a container does not have the required labels that container is denied access even if it is on the same internal docker network as socket-proxy.

Again relying on the information already available to socket-proxy through the docker socket it could restrict access via IP address gained through inspecting the container via the docker API. This could be further restricted through labels if necessary (but I could see this being unneeded complexity)

This approach could be a clean solution that wouldn't necessarily introduce any new configuration files and would also not require maintaining the configuration file for new services as they appear.

Of course a configuration file still may be prudent since these labels must be transformed into runtime configuration objects anyway.