Here is what happens Docker adds a bridge to the Linux OS named ‘docker0‘ and that bridge is an isolated network defined in software.
If the Docker daemon is running with both –icc=false and –iptables=true then, when it sees docker run invoked with the –link= option, the Docker server will insert a pair of iptables ACCEPT rules so that the new container can connect to the ports exposed by the other container – the ports that it mentioned in the EXPOSE lines of its Dockerfile Once you install Docker in Linux, a ‘default’ networking configuration is applied. When testing this on Ubuntu 16.04.3, unfortunately, despite documentation indicating that “–link” will automatically create iptables rules to enable cross docker network container access, this proved not to be the case when running Ubuntu 16.04.3. I also found that inter container communication still worked, despite ICC being disabled. The caveat being that to enable cross-container communication you have to use the “–link” argument when launching containers in order for the docker daemon to automatically create the required iptables rules to enable communication between containers on exposed ports. Docker has a built in capability called ICC that can be disabled in order to provide Docker Container Network Isolation. there is limited container network isolation in the event of a container being compromised. - The IP of the Docker bridge network if one exists.
TL:DR: when testing Docker with “–icc=false” on Ubuntu Server 16.04.3 I found that br_netfilter was required but not configured by default. Even when enabled, I found that the Docker Host physical network was not protected against container breakout. Testing with IP Masquerade disabled addressed Docker Host physical network security, however, with ICC and IP Masquerade disabled it was just as “easy” to manage the environment with “–iptables=false” and a firewall script. Docker has a built in capability called ICC that can be disabled in order to provide Docker Container Network Isolation.