Docker is still silently punching holes in your firewall after 5 years | Hacker News Reader

Docker is still silently punching holes in your firewall after 5 years

github.com

23 pointsgizzlon8 comments

Well, it literally says so in the documentation...

https://docs.docker.com/network/iptables/

By default, all external source IPs are allowed to connect to the Docker host. To allow only a specific IP or network to access the containers, insert a negated rule at the top of the DOCKER-USER filter chain.

3-4 levels deep?

It should be a big red box with warnings signs all over in the "Getting Started" docs

The "Getting Started" is meant to get one going with a "try-it-out" setup as fast as possible, not as a comprehensive guide on what to look out for in a production setting.

Admins can be expected to Read-The-Fine-Manual.

So, it doesn't endanger development machines on public wifis?

For most public-facing deployed services, I tend to run docker in `--iptables=false` mode with `--net=host` containers. Then you can just use normal iptables INPUT rules with your choice of firewall tooling. Works great with IPv6 as well, and fewer moving parts.

For special cases like CI servers where you need to be able to run multiple instances of the same set of containers simultaneously and have them talk to eachother on the same port... better have an external firewall to isolate the machine. Trying to manage the iptables ruleset is a mess (you can't use nftables or iptables-restore), and it's not reliable.

net=host is also bad for security. It's not recommended to do this, there was at least one severe security bug in containerd.

According to docker, you use Dockers internal network.

I learned this from HN and was very surprised :O

So in case this is new to you, as it was to me up until recently:

> "By default docker is munging the firewall in a way that breaks security - it allows all traffic from all network devices to access the exposed ports on containers."

Reply on news.ycombinator.com