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?

[wollomatic]

Hi @amanda-wee,

Thank you for taking the time to share such thoughtful suggestions, and my apologies for the delayed response.

1. Automated Testing:
   I fully agree - automated tests are a great idea. My goal is to improve the overall code quality of socket-proxy, and given its evolved structure, a comprehensive refactoring makes sense. However, I’d prefer not to proceed without introducing more tests first, as I want to avoid any unintended behavioral changes.

2. & 3. Feature Requests:
   Both points are valid. As you know, I aim to keep this tool as simple and focused as possible to ensure reliability and stability. While these features aren’t a priority for my own use case, I’m happy to support them if there’s broader community interest. That said, I likely won’t have the bandwidth to implement them myself this year.

3. Docker Swarm:
   While I don’t currently use Docker Swarm, I recognize it as an interesting area worth exploring in the future. Additionally, I’ve set up a Fedora test system with Podman, as questions about socket-proxy and Podman compatibility keep coming up.

4. Allowlist presets / ease of use:
   This is a great point.. Ma aim is prioritizing security by explicitly allowing only what’s needed. However, this approach can make onboarding harder compared to other socket proxies. I’ve considered building a companion tool to translate common configurations (e.g., BUILD=0, CONTAINERS=1) into the required regex patterns.

Thanks again for your input. I really appreciate it!

Best regards,
Wolfgang

[Rycochet]

Regarding presets, I've done some env variables (as I'm migrating over), which make it somewhat easier to configure - so something like -allowGET="($SP_VERSION|$SP_PING)" etc - they're all anchored at the start (so no bypassing by query string), and allow any optional version number - it could technically be a bit more optimised (by splitting the "any api version" prefix out), but that would make it more complicated to implement :-P

SP__PREFIX="(/v[\d\.]+)?" # allow any api version

SP_EVENTS="$SP__PREFIX/events.*" # mostly harmless
SP_PING="$SP__PREFIX/_ping" # mostly harmless
SP_VERSION="$SP__PREFIX/version" # mostly harmless

SP_AUTH="$SP__PREFIX/auth" # security critical
SP_SECRETS="$SP__PREFIX/secrets" # security critical

SP_ALLOW_PAUSE="$SP__PREFIX/containers/[a-zA-Z0-9_.-]+/pause"
SP_ALLOW_RESTARTS="$SP__PREFIX/containers/[a-zA-Z0-9_.-]+/(stop|restart|kill)" # migrating wants the same behaviour
SP_ALLOW_START="$SP__PREFIX/containers/[a-zA-Z0-9_.-]+/start"
SP_ALLOW_STOP="$SP__PREFIX/containers/[a-zA-Z0-9_.-]+/stop"
SP_ALLOW_UNPAUSE="$SP__PREFIX/containers/[a-zA-Z0-9_.-]+/unpause"
SP_BUILD="$SP__PREFIX/build"
SP_COMMIT="$SP__PREFIX/commit"
SP_CONFIGS="$SP__PREFIX/configs"
SP_CONTAINERS="$SP__PREFIX/containers"
SP_DISTRIBUTION="$SP__PREFIX/distribution"
SP_EXEC="$SP__PREFIX/exec"
SP_GRPC="$SP__PREFIX/grpc"
SP_IMAGES="$SP__PREFIX/images"
SP_INFO="$SP__PREFIX/info"
SP_NETWORKS="$SP__PREFIX/networks"
SP_NODES="$SP__PREFIX/nodes"
SP_PLUGINS="$SP__PREFIX/plugins"
SP_SERVICES="$SP__PREFIX/services"
SP_SESSION="$SP__PREFIX/session"
SP_SWARM="$SP__PREFIX/swarm"
SP_SYSTEM="$SP__PREFIX/system"
SP_TASKS="$SP__PREFIX/tasks"
SP_VOLUMES="$SP__PREFIX/volumes"

[wollomatic]

https://socket-proxy-configurator.wollomatic.dev/

So it has come to this :)

[amanda-wee]

That looks good, and I think it means presets would not be that useful now. I note that of the three example endpoints, only ping actually supports both GET and HEAD, whereas the other two only support GET. Perhaps it would be better to adjust the output to account for that?

[wollomatic]

Thanks @amanda-wee for the feedback. I fixed the example in the documentation according to the actual behaviour.
Next step is to provide an example with all configurable values.

[Rycochet]

@wollomatic That feels like a nice start - but there's a lot of fluff and duplicated examples for them - the default one can be cleaned up quite a bit using the regex I pasted above -

- '-allowGET=(/v[\d.]+)?/_ping'
- '-allowGET=(/v[\d.]+)?/events.*'
- '-allowGET=(/v[\d.]+)?/version'
- '-allowHEAD=(/v[\d.]+)?/_ping'
- '-allowHEAD=(/v[\d.]+)?/events.*'
- '-allowHEAD=(/v[\d.]+)?/version'

Of note - the /v<version> is optional and you don't ever need to end with .* as there's no end anchor. There's also a start anchor ^ to stop someone from requesting another endpoint and putting a valid one on the end of the url to bypass it (ie /security_nightmare?/_ping)

edit: Removed unnecessary anchors!

[amanda-wee]

The start anchor will be added by socket-proxy along with the end anchor when it processes the allowlist patterns. That's the reason why if you want to allow for sub-endpoints or the query string, you would need to add in .* or something more complex.

[Rycochet]

@amanda-wee Doh - I completely missed that part of the docs - I'll edit both my replies to fix them!

Use Go's regexp syntax to create the patterns for these parameters. To avoid insecure configurations, ^ and $ are added automatically to the start and end of the pattern. Note: invalid regexp results in program termination.

[wollomatic]

Thanks @Rycochet and @amanda-wee for the feedback. I’ve just deployed a slightly improved version. A hard browser reload may be needed.

[GitJaxder]

This may be off topic for this discussion specifically, but I was wondering if you could implement a change to Line 27 in Config.go:

socket-proxy/internal/config/config.go

Line 27 in 08dca43

const allowedDockerLabelPrefix = "socket-proxy.allow."

As it stands currently, there is only a single allowed label prefix: "socket-proxy.allow". The change would be setting the prefix to be something like "{hostname}.allow" where "hostname" is a variable that reads in os.Hostname().

So you could have two socket-proxy containers: traefik-socket-proxy and gameserver-socket-proxy. Then you'd apply labels "traefik-sock-proxy.allow*" to the containers that you want Traefik to control and "gameserver-socket-proxy.allow*" labels to gameservers that an uptime instance monitors.