Skip to content

Conversation

@niklasteichmann
Copy link

This PR includes the following changes:

  • set Poetry to not run in package-mode
  • upgraded base image tag from haproxy:2.2-alpine to haproxy:lts-alpine
  • resolved permission issues cause by user in base image changing from root to haproxy
  • updated tests
  • updated documentation

WARNING!
This PR will change how the image is used. An additional parameter --group-add=<docker_group_gid> is required to give the container's user (haproxy) permissions to access the Docker socket.

- upgraded base image tag from haproxy:2.2-alpine to haproxy:lts-alpine
- resolved permission issues cause by user in base image changing from root to haproxy
- updated tests
- updated documentation

frontend dockerfrontend
bind ${BIND_CONFIG}
bind "$BIND_PORT" "$BIND_OPTIONS"
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To make it possible to disable ipv6 via env I had to make this change in the HAProxy config. It works, but leads to warnings on start.

If someone knows a better way to do this, let me know.

@niklasteichmann
Copy link
Author

niklasteichmann commented Jun 30, 2025

I additionally upgraded the version of the Ubuntu image used for the Github jobs to ubuntu-latest and the version of the actions/cache to v4, so that the workflow runs again.

Let me know if you would prefer something different here.

@josep-tecnativa
Copy link
Contributor

josep-tecnativa commented Jun 30, 2025

Thank you for the update!

  • The GitHub Actions tweaks look solid.
  • I think that ubuntu-24.04 should be pinned for LTS stability
  • Have you run end-to-end tests with the new haproxy:lts-alpine non-root setup—i.e. the socket proxy still forwards correctly and it runs on a default Docker host without extra privileges?

@niklasteichmann
Copy link
Author

niklasteichmann commented Jun 30, 2025

Thanks for the feedback, I pinned the Ubuntu image version to 24.04.

I did some basic end-to-end tests. Running this set of commands:

docker container run \
    -d \
    --group-add "$(getent group docker | cut -d: -f3)" \
    --name dockerproxy \
    -v /var/run/docker.sock:/var/run/docker.sock \
    -p 127.0.0.1:2375:2375 \
    -e CONTAINERS=1 \
    docker-socket-proxy:local
export DOCKER_HOST=tcp://localhost:2375
# wait for container to start
sleep 1
# should work
docker container ls
# should return 403
docker image ls
# should return 403
docker rm --force dockerproxy

I received this output:

CONTAINER ID   IMAGE                       COMMAND                  CREATED         STATUS        PORTS                      NAMES
5adc5cbf7063   docker-socket-proxy:local   "docker-entrypoint.s…"   2 seconds ago   Up 1 second   127.0.0.1:2375->2375/tcp   dockerproxy

Error response from daemon: <html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Error response from daemon: <html><body><h1>403 Forbidden</h1>
Request forbidden by administrative rules.
</body></html>

Which looks good to me.

@josep-tecnativa
Copy link
Contributor

Adding group_add in every docker-compose.yml would break existing setups.
Could the entrypoint script automatically detect the socket’s GID and add the haproxy user to that group? That way the image stays non-root and keeps working out-of-the-box with plain Compose stacks.

@niklasteichmann
Copy link
Author

niklasteichmann commented Jul 1, 2025

Adding the haproxy user to the docker group would require root privileges.

And because the GID of the docker group can vary from system to system, we can't do this during the image build.

What we could do is start the entrypoint script as root, add haproxy to the docker group, switch to the haproxy user and continue from there. I don't know if this is a good idea - what do you think?

@josep-tecnativa
Copy link
Contributor

It could be fine for us. If you want, do the change please and I will test if it works properly.

- moved most of docker-entrypoint.sh into start-haproxy.sh
- made container run as root initially, assign group of docker socket to haproxy user and execute start-haproxy.sh as haproxy
- passthrough positional parameters to start-haproxy
- updated documentation
@niklasteichmann
Copy link
Author

niklasteichmann commented Jul 2, 2025

I've implemented your proposed solution. Let me know what you think!

Edit:
I am especially curious how the image behaves on SELinux , but didn't have the time to test it myself. Do you maybe have one set up to test on?

@niklasteichmann
Copy link
Author

@josep-tecnativa Sorry for pinging you directly, but did you have time to test?

@josep-tecnativa
Copy link
Contributor

Sorry, not yet. I will try to test it this week.

@niklasteichmann
Copy link
Author

niklasteichmann commented Jul 28, 2025

Hi @josep-tecnativa, sorry again for being obnoxious, but do you think you will have time to test this week?

@niklasteichmann
Copy link
Author

I just started using an internal fork including the changes from this PR for my customers. If something comes up, I will document it here.

@niklasteichmann
Copy link
Author

Practical testing has shown that the solution implemented here (starting the container as root and adding the docker group to the haproxy user) is unreliable. My preferred solution unfortunately breaks existing setups.

So I will instead fork the repo permanently and close this PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants