Updated the underlying haproxy version from 2.2 to 3.2.4

[Programmer-Admin]

Changes Incorporated:

1. Upgraded haproxy version to 3.2.4 from 2.2
2. Since haproxy now runs as haproxy user line #102, I placed haproxy.cfg file, inside /tmp. That makes no security tampering from USER side from inside of our Dockerfile.
3. Changed the docker-socket-proxy version from 0.0.0 to 1.0.0, since we upgraded the haproxy to a major version.

Happy to contribute.

[pedrobaeza]

Are you aware of the problems depicted here: #149 (comment) ?

[Programmer-Admin]

@pedrobaeza - Yes, I am aware of #149 , that is why I am not starting the container as root, also no docker group addition is required in this setup. I tested this setup on multiple open source services, it is working as expected. Please let me know, if you feel otherwise. This setup does not requires any group addition in docker as was discussed in #149 (comment)

[pedrobaeza]

OK, great, but please check CI.

[Programmer-Admin]

I'm stuck in fixing the CI 😞. It would be of great help if someone could help me on that.

[josep-tecnativa]

First of all, you could run pre-commit run -a to pass pre-commit stage.

[Programmer-Admin]

@josep-tecnativa - I ran, then I see all files find themselves in Git Staging Area, where I was expecting only haproxy.cfg and Dockerfile to only be in staging area. Kinda confused on this behavior.

[Programmer-Admin]

@pedrobaeza - Ok, finally I fixed CI part. Requesting you to please check.
Thanks @josep-tecnativa for helping me out!

[Programmer-Admin]

Hello @josep-tecnativa, @pedrobaeza,
Ok, I see what's happening here, I actually used Docker Socket Proxy Over Nginx Proxy(as TLS) which listens on 2376 and forward the request to underlying docker-socket-proxy container. But, what I was not aware that the tests will be running with only this container being executed standalone, and then checking a couple of tests. Sorry for bothering you. Can you please check whether my approach works. Thanks!

[Programmer-Admin]

@josep-tecnativa / @pedrobaeza - Could you please approve the workflow, so that I can check if something went wrong down the line. Thanks!

[pedrobaeza]

Done, @Programmer-Admin

[Programmer-Admin]

Many thanks @pedrobaeza. Seems like all checks passed. Now over to you for approval.

[pedrobaeza]

OK, my colleague @josep-tecnativa will check, but at least the commits should be squashed into one.

[josep-tecnativa]

Looks good to me!

Just squash your commits and we will merge.

[pedrobaeza]

Restore the line as it was for not having unneeded diff, please.

[pedrobaeza]

This is still pending.

[Programmer-Admin]

@pedrobaeza - I was actually thinking of keeping the use_backend and default_backend in separate section. Can we have that like this way? Or you want me to remove the new line before default_backend

[pedrobaeza]

They are not different sections in fact. I prefer to keep the diff minimal and don't add noise in any change.

[Programmer-Admin]

@pedrobaeza - Could you please check now?

[pedrobaeza]

Please squash together all the commits.

[Programmer-Admin]

Please squash together all the commits.

I am unfamiliar with the squashing command. Can you please help me out? What command to issue for achieving squash.

[josep-tecnativa]

Please squash together all the commits.

I am unfamiliar with the squashing command. Can you please help me out? What command to issue for achieving squash.

You can squash the commits using an interactive rebase. For example:

git fetch origin
git rebase -i origin/master

In the editor that opens, leave the first commit as pick and change all the others to f (for fixup) or s (for squash). Then save and close the editor.

This will combine all the commits into a single one on top of master. Finally,you will need to push with force:

git push --force

[Programmer-Admin]

Thanks for the help @josep-tecnativa. Commits successfully squashed.

[niklasteichmann]

Hi,
The solution you implemented is giving the user in the image root permissions. I'm not sure if that's a good idea - but it's not worse than it was before the upgrade, so maybe that's okay for now. I'd just like to hear your thoughts about this.

[Programmer-Admin]

@niklasteichmann - you are correct, it's not a good practice of giving Root user access inside docker image. But, if you see the original docker socket proxy image, even though we are not defining root in Dockerfile in the earlier version, if you exec, you will see that the earlier image is also using root user, that root user is actually propagating to socket proxy image from haproxy:2.2-alpine. But, now haproxy user is getting inherited from haproxy image to our socket proxy image, due to which I am manually changing the user to Root, so that the migration will be seamless and smooth.

[Programmer-Admin]

@josep-tecnativa - can we please check on the merge status? Many Thanks

[niklasteichmann]

@Programmer-Admin Yeah, I understand that. It's the same level of security as before the base image upgrade. Maybe this can be resolved in a future PR, I'll keep using my fork for now.
Thanks for your work on this.

[josep-tecnativa]

Sorry for the delay @Programmer-Admin , i was on holidays.

Looks good to me, LGTM!