Skip to content

[FEAT] Configurable bind address for HAProxy listener #44

Closed as not planned

Description

@niclas197

Is this a new feature request?

  • I have searched the existing issues

Wanted change

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.

Tecnativa/docker-socket-proxy already supports this (although undocumented) via the BIND_CONFIG environment variable (introduced in this commit).

Proposed code change

In root/docker-entrypoint.sh, allow BIND_CONFIG to override the default:

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.

Activity

  1. github-actions commented on May 1, 2026

    @github-actions

    Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

  2. LinuxServer-CI commented on May 31, 2026

    @LinuxServer-CI
    Contributor

    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.

  3. upmcplanetracker commented on Jun 9, 2026

    @upmcplanetracker

    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.

  4. thespad commented on Jun 13, 2026

    @thespad
    Member

    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.

  5. moved this from Issues to Done in Issue & PR Trackeron Jun 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions