You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEAT] Configurable bind address for HAProxy listener #44
Add an optional environment variable (e.g. BIND_CONFIG) that controls the address HAProxy binds to, instead of always listening on all interfaces (:2375 / [::]:2375).
Reason for change
When the socket-proxy runs in a shared network (e.g. a Podman pod sharing a network namespace with other containers), the proxy is reachable by every container on that network, even though typically only one specific container needs it. Since the Podman pod controlls networking for the whole pod, it is not possible to add an additional internal-only network if one container needs to access other containers (e.g. a reverse proxy). Being able to bind the socket-proxy to 127.0.0.1 (loopback inside the netns, Podman pods share a loopback-adress) would limit access to co-located containers in the same pod / network namespace and reduce the attack surface, without requiring a separate isolated network just for the proxy.
if [ -z "${BIND_CONFIG}" ]; then
if [ "${DISABLE_IPV6}" = 1 ]; then
BIND_CONFIG=":2375"
else
BIND_CONFIG="[::]:2375 v4v6"
fi
fi
sed "s|@@BIND_PROTO@@|${BIND_CONFIG}|g" /templates/haproxy.cfg > /run/haproxy/haproxy.cfg
Usage example:
environment:
- BIND_CONFIG=127.0.0.1:2375
Default behavior stays unchanged when the variable is unset.
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
I proposed a feature request #46 to address this issue, but the developer rightly pointed out that the general use case for this ( Network=host ) is not good security practice.
I think at this point if the developers agree the issue can be closed.
While the risk of running the proxy as host is reduced with rootless, my concern is people not running rootless using this functionality without realising that they're potentially exposing their entire docker daemon to their LAN or even the internet.
Activity
github-actions commentedon May 1, 2026
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
LinuxServer-CI commentedon May 31, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
upmcplanetracker commentedon Jun 9, 2026
I proposed a feature request #46 to address this issue, but the developer rightly pointed out that the general use case for this (
Network=host) is not good security practice.I think at this point if the developers agree the issue can be closed.
thespad commentedon Jun 13, 2026
While the risk of running the proxy as host is reduced with rootless, my concern is people not running rootless using this functionality without realising that they're potentially exposing their entire docker daemon to their LAN or even the internet.