I have run into this firewall problem too (not in any sort of production environment, thankfully).
The problem is that your mental model of a firewall tends to be that it sits 'in front of' all applications on your machine. Docker breaks this assumption by implicitly inserting rules into iptables.
Worse still, if you then inspect the state of the firewall (using UFW), it does not show you any of the rules that Docker inserted, because those rules are on a separate iptables chain.
The problem, then, is the interaction between Docker and UFW. UFW is designed as a 'simple' frontend for iptables, for situations where the advanced configurability of iptables is unneccessary. If you manage the firewall using UFW, you are not really supposed to also inject 'raw' iptables rules, especially not on non-standard chains. However, this is exactly what Docker does.
Therefore, we end up in the hairy situation where Docker adjusts your firewall, but UFW does not provide any indication that anything has changed. Neither project considers this a bug, and they just point to each other for a solution.
Personally, I think it should be on Docker to, at the very least, throw up some warnings when it is about to change firewall rules, as this is clearly unexpected behavior for many users (despite Dockers claims to the contrary).
Docker is not implicitly doing anything.
The user requested for the port to get published and so docker published it.
As nice as it would be for Docker to be more configurable in terms of where rules get inserted, that would not have helped here because the user already misconfigured things (should be using docker networks for db access).
Technically docker even has a chain that you can throw rules into that will get hit before docker's rules... so it's there just very manual (instead of, say, having a ufw mode).
Docker is implicitly overriding existing rules by putting their own ones in front. The least it should do is to put a warning "hey, there are other rules here,I'm adding my own, please verify.
It should also have option (I only found "complete on/complete off" one) to "just" create its DOCKER* chains and leave the jumping to them to the user
Docker has a `DOCKER-USER` chain where the user can inject their own rules before docker's rules are run.
But even then, the user flat out should not be using `-p` unless they want to expose the service outside of the machine. That is the well documented networking model of docker. Docker also includes a network abstraction that should have been used here to give access to other services that need it and isolate it from the things that don't.
> The user requested for the port to get published and so docker published it.
Yes, which runs counter to how every other application works. If you ask, say, sshd to listen on port 22, your firewall will still sit in front of it, unless you explicitly poke a hole in it.
Listening on a port and opening a port are different things.
`-p` is for opening ports. Docker is not listening on behalf of the application. It is routing traffic to the application.
The problem is that your mental model of a firewall tends to be that it sits 'in front of' all applications on your machine. Docker breaks this assumption by implicitly inserting rules into iptables.
Worse still, if you then inspect the state of the firewall (using UFW), it does not show you any of the rules that Docker inserted, because those rules are on a separate iptables chain.
The problem, then, is the interaction between Docker and UFW. UFW is designed as a 'simple' frontend for iptables, for situations where the advanced configurability of iptables is unneccessary. If you manage the firewall using UFW, you are not really supposed to also inject 'raw' iptables rules, especially not on non-standard chains. However, this is exactly what Docker does.
Therefore, we end up in the hairy situation where Docker adjusts your firewall, but UFW does not provide any indication that anything has changed. Neither project considers this a bug, and they just point to each other for a solution.
Personally, I think it should be on Docker to, at the very least, throw up some warnings when it is about to change firewall rules, as this is clearly unexpected behavior for many users (despite Dockers claims to the contrary).