Next Steps

[amanda-wee]

I am happy to see that what began as a proof-of-concept for an interesting idea (container labels to specify per-container allowlists) has been released as something usable that addresses what does appear to be a pain point for some folks. I'm still game to improve socket-proxy in other areas, though I'm also aware that @wollomatic stated his "idea is to keep socket-proxy simple and stupid". My current thoughts on what could be implemented next:

1. Automated tests for per-container allowlists. I tested the feature manually, but at the very least we might be able to reintroduce tests of the parts of the Docker SDK for Go that was used.

2. Implement concurrent yet optional IPv4, IPv6, and Unix socket listeners. This was discussed in issue [Bug] defaultAllowFrom should also include ::1 #66 as it would fix the problem that was raised by OdinVex as a side effect.

3. Implement a way for the per-container allowlists feature to work with a proxy that enables containers on external hosts to have restricted access the Docker socket. While the Dozzle creator who raised issue Support for TLS #14 already has a solution for Dozzle that is better in its own Dozzle-specific way, vnghia proposed a more general workaround involving a reverse proxy configured for mTLS. The trouble as I understand it is that N external host containers would require N socket-proxy containers each with their own reverse proxy. I believe the per-container allowlists feature would simplify it to having 1 socket-proxy container with N reverse proxy containers, but ideally socket-proxy could support 1 socket-proxy container with 1 reverse proxy container.

4. Figure out how to get socket-proxy to support Docker Swarm. I don't use Swarm myself though, so this is not particularly appealing to me as I won't be eating my own dog food. Nonetheless, there does appear to be some demand for this.

5. Implement allowlist presets. The idea is that having to detail a bunch of regex patterns can be intimidating for a new user, so having a minimal preset, a readonly preset, etc., could ease adoption. An argument against this is that careless users could end up with an overly permissive configuration, but that's true even now if new users try something like '-allowGET=.*' and then neglect to make it more secure.

Any opinions and suggestions?