zlacker

>>todsac+(OP)
Docker has a known security issue with port exposure in that it punches holes through the firewall without asking your permission, see https://github.com/moby/moby/issues/4737

I usually expose ports like `127.0.0.1:1234:1234` instead of `1234:1234`. As far as I understand, it still punches holes this way but to access the container, an attacker would need to get a packet routed to the host with a spoofed IP SRC set to `127.0.0.1`. All other solutions that are better seem to be much more involved.

>>smarx0+P4
And this was one of the reason why I switched to Podman. I haven't looked back since.

>>anthro+x6
I want to use Podman but I keep reading the team feels podman-compose to be some crappy workaround they don’t really want to keep.

This is daunting because:

Take 50 random popular open source self-hostable solutions and the instructions are invariably: normal bare installation or docker compose.

So what’s the ideal setup when using podman? Use compose anyway and hope it won’t be deprecated, or use SystemD as Podman suggests as a replacement for Compose?

>>MortyW+xa
There is a third option: enable the Docker socket and use Docker Compose as usual.

https://github.com/containers/podman/blob/main/docs/tutorial...

>>Cyph0n+4b
Docker Compose would not prevent you from doing a "publish port to 0.0.0.0/0", it's not much more than a (very convenient) wrapper around "docker build" and "docker run".

And many if not as good as all examples of docker-compose descriptor files don't care about that. Images that use different networks for exposed services and backend services (db, redis, ...) are the rare exception.

>>mschus+jl
Are you sure about that? Because I was under the impression that these firewall rules are configured by Docker. So if you use Docker Compose with Podman emulating the Docker socket, this shouldn’t happen.

Maybe someone more knowledgeable can comment.