Connecting Containers and Network Isolation

A container is not limited to one network. It can join several at once, and that is how you isolate tiers. A reverse proxy sits on a public-facing network and a backend network; the database sits only on the backend; nothing on the public network can reach the database, because they share no network. Isolation is a property of which networks a container is on — not an accident of which containers happen to coexist.

docker network connect and docker network disconnect attach and detach a running container without recreating it, so the topology is something you build and adjust deliberately. The default between two separate user-defined networks is that they cannot reach each other; you make connectivity, you do not have to prevent it.

Multiple Networks per Container

A container attached to several networks gets an interface and an IP on each, and resolves names on every network it shares. That is what lets one container bridge two otherwise-isolated tiers: it is the only thing on both, so it is the only path between them. Everything else on either network stays walled off from the other.

The Two-Tier Pattern

The pattern is two networks and a straddling container. A frontend network carries proxy and web; a backend network carries web and db. proxy is on frontend only; db is on backend only; web sits on both. Because proxy and db share no network, proxy can never open a connection to db directly — there is no route, no name resolution, nothing. The only way to the database is through web.

docker network create frontend
docker network create backend

docker run -d --name db    --network backend  postgres:16
docker run -d --name web   --network backend  driftwood:latest
docker network connect frontend web          # web now straddles both tiers
docker run -d --name proxy --network frontend -p 80:80 -p 443:443 nginx

web is created on backend so it can reach db, then docker network connect frontend web attaches it to frontend as well, so proxy can reach it. proxy and db never touch a shared network, which is the entire point of the layout.

Why db Is Segmented

Keeping db off any network that the public-facing proxy can reach means a compromise of proxy cannot open a connection to PostgreSQL. An attacker who lands inside proxy finds no route to db at all — they would first have to compromise web. This is defense in depth that publishing rules alone do not provide: not publishing db's port stops the outside world, but network segmentation stops a compromised peer too.

connect and disconnect at Runtime

docker network connect backend web attaches a running container to a network, and docker network disconnect backend web removes it — both without recreating the container or interrupting its other connections. That is useful for attaching a debug container to a network temporarily to poke at a service, or for migrating a container between networks during a change, rather than tearing it down and starting over.

Inspecting the Topology

docker network inspect backend lists which containers are attached and their addresses, and docker inspect db shows every network a container is on. Reading these is how you verify the isolation actually holds — that db really is on backend only, and that nothing public-facing has quietly been attached to it. Trust the inspect output, not your memory of which commands you ran.