Bridge Networking in Docker: An Overview of Network Isolation in a Container Environment

Bridge Networking in Docker: An Overview of Network Isolation in a Container Environment

In the world of Docker, deploying a container is not simple; properly configuring a container architecture requires strong networking capabilities. A web application with a cluster of databases, applications, and load balancers spanning numerous containers that need to communicate with one another would have a different network architecture than one designed to run on a single Docker container.

Networking allows containers to communicate with each other and with the host system. Containers run isolated from the host system and need a way to communicate with each other and with the host system.

Docker's Default Networks

Three network drivers/interfaces with different use cases are automatically created for you when you install Docker:

Docker Networks - Bridge driver network - 2020

Bridge (docker0)

A container connects to this network when it starts running without specifying a network. Containers connected to the bridge network are given an internal IP address to communicate with each other.

Host

A container shares the networking namespace of the host when using the host network mode. As a result, the host's IP address and port will be used by the container to isolate and execute the process directly on the host.

None

As the name indicates, this mode disables the networking stack of the container. The host, other containers, and external systems are all inaccessible to containers running without network. It becomes useful when you do not require any network connectivity or complete isolation.

To view all networks, including the default ones, you can use the command:

docker network ls

The output is as:

Bridge Networking; An interactive demo

The default network mode in Docker. It creates a private network between the host and containers, allowing containers to communicate with each other and with the host system.

image

If you want to secure your containers and isolate them from the default bridge network, you can also create your own bridge network.

docker network create -d bridge <my_bridge_name>

Now, if you list the available networks, the new bridge is added.

docker network ls

NETWORK ID          NAME                DRIVER
xxxxxxxxxxxx        bridge              bridge
xxxxxxxxxxxx        my_bridge_name      bridge
xxxxxxxxxxxx        none                null
xxxxxxxxxxxx        host                host

Now, if you want to see containers' details in the bridge network, you can use the following command:

docker network inspect bridge

For a demo, we run two containers named viz. login and logout using command:

docker run -d --name login nginx:latest
docker run -d --name logout nginx:latest

Now, if we hop in to the running login container using command:

docker exec -it login /bin/bash

Currently the running containers are:

Now, if we run the command

docker inspect logout

We see that its IP address is 172.17.0.1

Now returning back to the interactive bash of login, if we ping the IP address of logut (172.17.0.1), we get:

This means that, both the login and logout are now connected via a bridge network.

Now, we create a new network named secure-network using the command:

docker network create secure-network

Now, in this network, we isolate a new container named finance.

We run a new named container named finance under this network using the command:

docker run -d --name finance --network=secure-network nginx:latest

Now, if we inspect the info of this container using command:

docker inspect finance

We see that the IP of this container is in new subnet, which in our case is 172.19.0.1

Moreover, the network is also secure-network (for previous one, it was bridge).

Now, if we ping this from the login interactive bash, we cannot get any info of this container. This implies that our container is isolated from the other two. This enhances the security too.

In this way, we created the three containers, among which two were in same subnet and one was isolated from the other two.