Docker Container Networking and Isolation

User-defined bridges provide automatic name resolution between attached containers.

The command returns the full 64-character network ID on success. Behind the scenes Docker allocates the next free private subnet, creates a bridge interface on the host (visible as br-<id> in ip link on Linux), and programs iptables rules that NAT outbound traffic and block inbound traffic from other bridges.

Common mistake: running this twice and getting Error response from daemon: network with name app-net already exists. That error is harmless, the network is already there and you can move on. If you genuinely want to start over, remove it with docker network rm app-net first (it must have no attached containers).

Optional hardening: pin the subnet yourself so it never collides with a VPN or LAN range, e.g. docker network create --subnet 10.90.0.0/24 app-net.

Expected output:

$ docker network create app-net
8f2c1a4b5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2c3d4e5f6a7b8c9d0e1f2a3

What this teaches: A user-defined network is a private bridge with its own subnet; creating it is what enables everything after.

Run the database first, then the frontend. The --name flag matters twice here: it gives you a handle for docker exec, and it becomes the DNS record other containers on app-net resolve. Note that the official postgres image refuses to start without a password, so we set POSTGRES_PASSWORD explicitly (a throwaway lab value, never use a real secret this way):

START THE DATABASE AND THE FRONTEND ON APP-NET

docker run -d --name db --network app-net \
  -e POSTGRES_PASSWORD=labpass \
  postgres:16

docker run -d --name web --network app-net nginx:stable

Expected output:

$ docker run -d --name web --network app-net nginx:stable
a1b2c3d4e5f60718293a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f

Flag by flag: -d detaches, --network app-net places the container on our bridge instead of the default one, and -e passes an environment variable into the container. Neither command publishes a port, so nothing is reachable from the host yet, exactly what we want for the database.

Verify both containers are actually running and on the right network:

Notice db shows 5432/tcp with no host mapping, the port is open inside the container but not published. If db is missing from the list, run docker ps -a; a postgres container that exits immediately almost always means the password variable was forgotten, which docker logs db will confirm.

Common mistake: omitting --network on one of the two containers. It silently lands on the default bridge, and step 03's name lookup will fail. When in doubt, check with docker inspect -f '{{json .NetworkSettings.Networks}}' db.

What this teaches: Attaching containers to the same network is what puts them on the same broadcast domain; placement is the policy.

Now prove the embedded DNS works. From inside web, resolve the name db:

This works because every container on a user-defined network gets a resolv.conf pointing at Docker's embedded DNS server, which listens on 127.0.0.11 inside the container's network namespace. That server forwards real internet lookups upstream but answers container names itself, and only for networks the asking container is attached to:

How to verify it is DNS and not luck: re-create db (docker rm -f db then re-run it) and resolve again. The IP may change, but getent hosts db still answers correctly because Docker updates its records on container start and stop. Anything caching the old IP, a connection pool, for instance, would need to reconnect, which is exactly why apps should connect by name and never pin container IPs.

Scoped aliases: besides its container name, a container can answer to extra names per network via --network-alias. A container started with --name db --network app-net --network-alias postgres-primary resolves under both names on app-net, useful for giving a container a stable service identity while the container name itself stays free to change.

Common mistake: testing from a container on the default bridge and concluding "DNS is broken". The default bridge has no embedded DNS names; the lookup only works between containers sharing a user-defined network.

Expected output:

$ docker exec web getent hosts db
172.19.0.3      db

What this teaches: Embedded DNS is the payoff: names resolve to current IPs, so restarts do not break connectivity.

Before trusting a topology, look at it. docker network inspect dumps the subnet, gateway, and every attached container with its IP:

EXPECTED OUTPUT (ABRIDGED)

[
    {
        "Name": "app-net",
        "Driver": "bridge",
        "IPAM": {
            "Config": [
                {
                    "Subnet": "172.18.0.0/16",
                    "Gateway": "172.18.0.1"
                }
            ]
        },
        "Containers": {
            "3f4a...": {
                "Name": "db",
                "IPv4Address": "172.18.0.2/16"
            },
            "9c1b...": {
                "Name": "web",
                "IPv4Address": "172.18.0.3/16"
            }
        }
    }
]

Expected output:

$ docker network inspect app-net --format '{{.IPAM.Config}}'
[{172.19.0.0/16  172.19.0.1 map[]}]

For scripting, filter instead of reading the whole blob: docker network inspect -f '{{json .Containers}}' app-net. The Containers map is your ground truth for "who can talk to whom by name", if a container is not listed here, it is not on this network no matter what you intended.

What this teaches: Inspecting the bridge shows the machinery: subnets, gateways, and which containers hold addresses.

Name resolution alone does not prove the port is reachable. The nginx image is Debian-based and ships bash, so we can use bash's /dev/tcp pseudo-device as a dependency-free TCP probe, no need to install nc or curl:

Cross-check from the database side with postgres's own health tool, which confirms the server is not just listening but accepting connections:

Common mistake: declaring victory after ping db succeeds. ICMP only proves the container is up; the service can still be down or listening on a different port. Always probe the actual port, as above.

Optional, a real client handshake: if you want proof at the application layer rather than the TCP layer, run the postgres client from a throwaway container on the same network. It will authenticate and return a row:

This is the same pattern every real app follows: a service name (db), a port (5432), and credentials passed by environment variable, the exact triad you will later write into a Compose file or a Kubernetes manifest.

Expected output:

$ docker exec web sh -c 'echo > /dev/tcp/db/5432' && echo "db reachable"
db reachable

What this teaches: App-to-database connectivity is the real-world test; the app never knows it is in a container.

Isolation means nothing until something is actually on the outside trying to get in. Create a second bridge and attach a long-running Alpine container to it. This container stands in for anything that shares the Docker host but has no business talking to your database, a compromised sidecar, a neighbour tenant, a leftover debug container:

SECOND NETWORK PLUS AN OUTSIDER CONTAINER

docker network create other-net
docker run -d --name unrelated --network other-net alpine:3.20 sleep 3600

Expected output:

$ docker network create other-net
c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b3c4d

The sleep 3600 keeps Alpine alive for an hour; without a long-running command the container would exit instantly and have nothing to probe from.

Confirm the new topology before attacking it. docker network ls should now show four custom-relevant entries, and each network's inspect output should list exactly the containers you put there:

Note that other-net received its own subnet (172.19.0.0/16), Docker allocates these sequentially. The unrelated container has an interface on other-net only; it has no route into 172.18.0.0/16 at all.

What this teaches: A second network is a second broadcast domain; networks are the isolation boundary.

Attack it two ways. First, name resolution from unrelated fails outright, db is not a record on other-net, so the embedded DNS answers with nothing:

Second, and more important, even if the attacker learns the database IP out of band, the traffic itself is blocked because the two bridges are separate L2 domains with iptables rules between them:

That second test is the one that matters for security. DNS failure is a convenience barrier; the L2/iptables separation is the real wall. If you ever do need a container to span both worlds, say a monitoring agent, the surgical tool is docker network connect app-net unrelated, which adds a second interface to a running container rather than flattening the networks together.

Expected output:

$ docker exec outsider ping -c1 db
ping: bad address 'db'

What this teaches: A failed ping is a successful experiment: it proves the isolation is real, not assumed.

Right now the application works internally but is unreachable from the host, which is safe and useless in equal measure. The frontend is the piece the outside world is supposed to reach, so publish its port, and only its port. Ports are set at container creation time, so recreate web:

RECREATE WEB WITH A PUBLISHED PORT

docker rm -f web
docker run -d --name web --network app-net -p 8080:80 nginx:stable

Expected output:

$ docker ps --format '{{.Names}} {{.Ports}}'
web 0.0.0.0:8080->80/tcp
db  5432/tcp

Because web rejoins app-net under the same name, the DNS record is re-registered and nothing else changes. Verify from the host:

The pattern to internalize: the web tier is published (-p 8080:80), the database is not. An attacker who reaches the host can talk to nginx and nothing else; the database only exists on app-net. This is the container-era version of putting the DB in a private subnet.

Common mistake: publishing with -p 80:80 and colliding with something already on host port 80, or assuming -p can be added to a running container, it cannot. Port bindings are fixed at docker run time; changing them always means recreating the container, as we just did. Also note that EXPOSE in a Dockerfile is documentation only, it publishes nothing by itself.

What this teaches: Publishing one port is least privilege at the network edge; the database stays unreachable from the host.

Remove the containers first, a network with attached containers cannot be deleted, then the networks:

Do not tear down yet. The Testing & Validation section runs against these live containers and networks; the teardown commands are at its end.

Confirm with docker network ls and docker ps -a that only the three built-in networks and no lab containers remain. On a shared or long-lived host, docker network prune reclaims every unused custom network in one shot, useful, but be sure nothing else on the host is relying on an idle network before running it.

What this teaches: Cleanup removes the bridges and their iptables rules; leftover networks are a common source of confusion later.