3 ms·

If such an obvious thing happens to a company because they're too smart to read documentation, they would have run into big problems with LXD or sd-machined, to

If such an obvious thing happens to a company because they're too smart to read documentation, they would have run into big problems with LXD or sd-machined, too.

spiffytech 4y ago
I disagree that this is obvious or reflects an inappropriate attitude. This is a case where a tool you trust (ufw) lies to you because Docker not only unexpectedly adds iptables rules for simple scenarios, but adds them at a higher priority than your firewall. Software doesn't normally modify your firewall when it binds to a port, and firewalls exist to restrict port exposure. Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes). If Docker was a simple tool with brief docs, I could agree, but Docker's docs are so extensive that knowing everything it does isn't practical. One just has to hope they stumble into docs on footguns. It's hard for me to call this behavior "obvious" without basically invalidating footguns as an idea.
- quectophoton 4y ago
  > Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes). Adding to this. I really don't blame people (not even my past self) for: * Expecting `-p 8001:8002` to behave the same way as the unprivileged `ssh -L 0.0.0.0:8001:${CONTAINER_IP_IN_ONE_DOCKER_SUBNET}:8002`. * Expecting `ufw` to pickup changes in firewall rules. * Trusting the offline `man 1 docker-run`. Even knowing what I know now (I'm still pretty ignorant, but a little bit less than in the past), I still consider this a bad default from the Docker CLI. Yes, `docker run` needs privileges for other stuff, but since the forwarding part can be done without punching a hole, I don't think it's unreasonable to expect it to be done that way. Even just mentioning the word "iptables" in `docker-run(1)` would go a long way.

If such an obvious thing happens to a company because they're too smart to read documentation, they would have run into big problems with LXD or sd-machined, too.

spiffytech 4y ago

I disagree that this is obvious or reflects an inappropriate attitude. This is a case where a tool you trust (ufw) lies to you because Docker not only unexpectedly adds iptables rules for simple scenarios, but adds them at a higher priority than your firewall. Software doesn't normally modify your firewall when it binds to a port, and firewalls exist to restrict port exposure. Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes). If Docker was a simple tool with brief docs, I could agree, but Docker's docs are so extensive that knowing everything it does isn't practical. One just has to hope they stumble into docs on footguns. It's hard for me to call this behavior "obvious" without basically invalidating footguns as an idea.

quectophoton 4y ago
> Docker adding iptables rules is understandable once you realize the full power of Docker networking, but I feel it's reasonable for people to not predict that behavior, given such power is beyond many people's use cases. (FWIW, rootless podman doesn't alter iptables, validating the proposition that using Docker in simple scenarios doesn't lend itself to a mental model that predicts iptables changes). Adding to this. I really don't blame people (not even my past self) for: * Expecting `-p 8001:8002` to behave the same way as the unprivileged `ssh -L 0.0.0.0:8001:${CONTAINER_IP_IN_ONE_DOCKER_SUBNET}:8002`. * Expecting `ufw` to pickup changes in firewall rules. * Trusting the offline `man 1 docker-run`. Even knowing what I know now (I'm still pretty ignorant, but a little bit less than in the past), I still consider this a bad default from the Docker CLI. Yes, `docker run` needs privileges for other stuff, but since the forwarding part can be done without punching a hole, I don't think it's unreasonable to expect it to be done that way. Even just mentioning the word "iptables" in `docker-run(1)` would go a long way.