zlacker

[return to "A story on home server security"]
1. smarx0+P4[view] [source] 2025-01-05 13:38:36
>>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.

◧◩
2. anthro+x6[view] [source] 2025-01-05 14:01:02
>>smarx0+P4
And this was one of the reason why I switched to Podman. I haven't looked back since.
◧◩◪
3. MortyW+xa[view] [source] 2025-01-05 14:39:59
>>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?

◧◩◪◨
4. thedan+Cj[view] [source] 2025-01-05 15:55:57
>>MortyW+xa
I use docker compose for development because it's easy to spin up an entire project at once. Tried switching to podman compose but it didn't work out of the box and I wasn't motivated to fix it.

For "production" (my homelab server), I switched from docker compose to podman quadlets (systemd) and it was pretty straightforward. I actually like it better than compose because, for example, I can ensure a containers dependencies (e.g. database, filesystem mounts) are started first. You can kind of do that with compose but it's very limited. Also, systemd is much more configurable when it comes to dealing service failures.

[go to top]