How do you block container-to-container traffic on a Docker bridge network, and how does docker0 differ from a bridge you create?

## What ICC means "Inter-container communication" is the daemon's term for containers on the same bridge network being able to talk to each other. It is **on** by default, and it is more permissive than people expect: two containers on the same bridge can reach each other on **any** listening port, not only the ones declared with `EXPOSE` or published with `-p`. A container listening on 6379 with no published port is fully reachable from every peer on its bridge. On the default bridge that means every container on the host that did not ask for a network — including unrelated workloads — is a peer that can connect to your service. ## The two knobs **Default bridge (docker0):** a daemon setting. ``` { "icc": false } ``` in `/etc/docker/daemon.json` (equivalently `dockerd --icc=false`), applied at daemon start. It is engine-wide and changing it restarts the daemon, so it is a decision about the host, not about one application. **A bridge you create:** a driver option, set when the network is created and immutable afterwards. ``` docker network create --opt com.docker.network.bridge.enable_icc=false digest-jobs ``` Because it is per network, you can run one locked-down network beside ordinary ones on the same host. Because it is immutable, changing your mind means creating a replacement network and re-attaching the containers. ## How it is enforced, and what survives The daemon installs a rule that drops packets forwarded from the bridge back out of the same bridge — traffic between two containers on that network. That is a narrow cut, and four things deliberately keep working: * **Published ports.** `-p 8080:4567` still maps a host port and still accepts traffic from outside the host. Disabling ICC is not a substitute for not publishing something. * **Outbound traffic.** Containers still reach the internet and the host's other services through the usual masquerading; that is what `--internal` turns off, and it is a different control. * **Name resolution.** On a user-defined network, container names still resolve. Docker's embedded resolver is provided by the daemon inside the container's own namespace, not by a peer on the bridge, so lookups succeed while connections are dropped. * **Anything sharing a namespace.** A container started to share another container's network namespace is not a separate bridge peer at all. That combination produces the diagnostic signature: a name resolves to an address, and the connection to it times out. Engineers who assume "DNS answered, so the network is fine" chase the wrong thing for an hour. ## Where it is genuinely useful A 47-node CI fleet runs jobs from many teams, several containers per node, all on one job network. A Ruby email-digest builder's test job has no business connecting to a Postgres container belonging to another team's job on the same host, and there is nothing to stop it: neither container publishes a port, and both are on the same bridge. Creating the job network with `enable_icc=false` means each job's containers can still be reached by the runner through published ports and can still fetch dependencies outbound, but a job container cannot open a socket to a peer it was never meant to see. It removes the easiest lateral move on a shared build host. It is deliberately blunt: it is all-or-nothing for the network, with no per-port or per-pair allowance. Historically the pairing was `--icc=false` on the daemon plus `--link` to punch an allowance for the linked container's exposed ports; that legacy combination is not how anyone should build this today. ## How it relates to the other isolation controls Three controls are routinely confused: * **Separate networks** decide which containers can address each other at all — the usual, coarse, and most maintainable tool. * **`--internal`** decides whether a network can talk to the outside world. * **Disabling ICC** decides whether members of one network can talk to *each other*. If what you want is "the database is reachable only by the API", the answer is network layout, not ICC. If what you want is "nothing on this shared network may talk to its neighbours", ICC is the control. ## Verifying it After creating the network, start two containers on it and prove both halves: the name resolves, and the connection does not open. And state the limitation honestly in an interview: this is host-level plumbing, it applies to every container on the network equally, and it cannot express "A may reach B on 5432 but nothing else". Once requirements look like that, the answer is a different network layout or a policy layer above Docker, not more bridge options.