There's no alternative for 0.0.0.0 and a firewall if you're e.g. using kubernetes.

Dockers manipulation of nftables is pretty well defined in their documentation

Documentation people don't read. People expect, that, like most other services, docker binds to ports/addresses behind the firewall. Literally no other container runtime/engine does this, including, notably, podman.

As to the usage of the docker socket that is widely advised against unless you really know what you’re doing.

Too bad people don't read that advice. They just deploy the webtop docker compose, without understanding what any of it is. I like (hate?) linuxserver's webtop, because it's an example of the two of the worst footguns in docker in one

To include the rest of my comment that I linked to:

Do any of those poor saps on zoomeye expect that I can pwn them by literally opening a webpage?

No. They expect their firewall to protect them by not allowing remote traffic to those ports. You can argue semantics all you want, but not informing people of this gives them another footgun to shoot themselves with. Hence, docker “bypasses” the firewall.

On the other hand, podman respects your firewall rules. Yes, you have to edit the rules yourself. But that’s better than a footgun. The literal point of a firewall is to ensure that any services you accidentally have running aren’t exposed to the internet, and docker throws that out the window.

You originally stated:

I think from the dev’s point of view (not that it is right or wrong), this is intended behavior simply because if docker didn’t do this, they would get 1,000 issues opened per day of people saying containers don’t work when they forgot to add a firewall rules for a new container.

And I'm trying to say that even if that was true, it would still be better than a footgun where people expose stuff that's not supposed to be exposed.

But that isn't the case for podman. A quick look through the github issues for podman, and I don't see it inundated with newbies asking "how to expose services?" because they assume the firewall port needs to be opened, probably. Instead, there are bug reports in the opposite direction, like this one, where services are being exposed despite the firewall being up.

(I don't have anything against you, I just really hate the way docker does things.)

Probably not an issue, but you should check. If the port opened is something like 127.0.0.1:portnumber, then it's only bound to localhost, and only that local machine can access it. If no address is specified, then anyone with access to the server can access that service.

An easy way to see containers running is: docker ps, where you can look at forwarded ports.

Alternatively, you can use the nmap tool to scan your own server for exposed ports. nmap -A serverip does the slowest, but most indepth scan.

Docker will have only exposed container ports if you told it to.

If you used -p 8080:80 (cli) or - 8080:80 (docker-compose) then docker will have dutifully NAT'd those ports through your firewall. You can either not do either of those if it's a port you don't want exposed or as @moonpiedumplings@programming.dev says below you can ensure it's only mapped to localhost (or an otherwise non-public) IP.

Actually, ufw has its own separate issue you may need to deal with. (Or bind ports to localhost/127.0.0.1 as others have stated.)

If you are talking about the IP address then just add a static address, no? I do it anyway in my docker compose:

...
    networks:
      traefik.net:
        ipv4_address: 10.10.10.99

networks:
    traefik.net:
      name: traefik-net
      external: true

I'm not an expert so maybe I'm wrong, if so do not hesitate to correct me !

EDIT: If the IP address doesn't change, you do not need to change to routing and iptables/nftables rules. ??