I'd need finer-grained restrictions

[funkyfuture]

ciao, thanks for this simple solution. i'd have a use-case though where only access to the endpoints containers/json and …/{id}/json (inspection), but not …/create or …/{id}/stop etc., would be needed.

it'd be therefore desirable to use environment variables like CONTAINER_LIST and CONTAINER_INSPECT to override the CONTAINER value.

[yajo]

Thanks for your time on opening this issue. 😊

Usually CONTAINERS=1 POST=0 should be enough for your case, where you allow access to containers/*, but only allow GET and HEAD operations.

Please reopen if I missed something.

[funkyfuture]

well, my examples weren't the best. but there are other endpoints for GET requests, like export that are desirable to forbid.

[yajo]

OK, let me reopen. 😉

TBH most likely I'm not gonna work to fix this, since it doesn't affect the usage I do for this image. However if anybody wants to open a PR, feel free to do so! 😊

[funkyfuture]

#14 seems like a step in the right direction for that, but a standalone binary that generates the config as entrypoint would be preferable.

[HazardousBackup]

I think this issue should be looked at more closely because as it stands if you have something like Diun that should only really need containers/json, you'd give it CONTAINERS=1 but that will also give it access to containers/{id}/archive which would let it grab arbitrary files from any other container and containers/{id}/json which would give it the environmental variables for any running container which might include private information.

Neither one of those Diun would need to do (not that it uses them) and so it shouldn't have access to them. However, there is no way to deny access via this proxy.

[andrebrait]

Have you looked into https://github.com/wollomatic/socket-proxy? It seems to be able to essentially do the same as this project, but for any UNIX socket and it has quite fine-grained controls. The author has a sample Traefik setup using it here: https://github.com/wollomatic/traefik-hardened

This may give ideas on how to use that for a similar use-case.

[HazardousBackup]

If this is in reply to me, since I revived this topic, then my concern isn't really for myself.
I can get away without it or do modifications myself. I'm working on a modification for linuxserver/docker-socket-proxy for at least myself at the moment.

The reason I think this is important is that this project has over 10 Million pulls on Docker Hub and not everyone is going to catch these details about the API.

[andrebrait]

@HazardousBackup yes, it was for you. I believe the project I linked would be somewhat close to what your goal is. I understand linuxserver/docker-socket-proxy is a drop-in replacement to this, but in order to accomplish the finer grained permissions, it'll probably have to stop being that. If that's the case, then perhaps it's worth taking a look at the one I linked. It's probably easier to customize that to have a set of "templates" for popular services than it is to modify this to achieve the same level of customization.