Docker Networking 101: Default Bridge Mode

Docker networking allows containers to communicate with each other and the outside world. It is a crucial part of Docker, providing a way for applications within containers to send and receive data.

The Default Bridge Mode in Docker is a key networking mode that enables isolated communication between Docker containers and the host.

The Docker bridge driver (software device running within a host machine's kernel acting as a TCP/IP Link Layer device) automatically installs rules in the host machine so that containers on different bridge networks can't communicate directly with each other. This bridge driver acts as a virtual switch to which containers are connected.

Network Isolation

When running in bridge mode, each Docker container is connected to a private internal network hosted by the Docker daemon on the host machine. This network is isolated from the external network, providing a secure environment for container communication.

After Docker is installed, it creates a virtual network bridge, typically named docker0, on the host machine. This bridge acts as a virtual switch to which containers are connected.

Image credits: David Omokhodion

We can find the the interface of the default bridge network by using ifconfig or ip addr show commands:

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:90:68:1f:7f  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

To find the information about the default bridge network use docker network ls command:

NETWORK ID          NAME                DRIVER              SCOPE
f4d2e21e057a        bridge              bridge              local

NETWORK ID: f4d2e21e057a

This is a unique identifier for the network within the Docker system. Each Docker network is assigned an ID like this to differentiate it from others. It's used internally by Docker to manage networking functionalities.

NAME: bridge

This is the name of the network. In this case, bridge is the default network that Docker creates automatically. When you run a container and do not specify a network, Docker connects it to this bridge network by default.

DRIVER: bridge

The driver indicates the type of network. Here, the bridge driver is used, which is the standard network driver in Docker for creating a network on a single host.

The bridge driver creates a private network internal to the host so that containers on this network can communicate with each other. Containers on different bridge networks are isolated from each other.

SCOPE: local

This indicates the scope of the network's effect. local means that this network only facilitates communication on the local Docker host. Containers attached to this network will only be able to communicate with each other and the host on this single machine.

This is in contrast to networks with a global or swarm scope, which are used in more complex configurations like Docker Swarm, where containers might need to communicate across different hosts.

Internal IP Addressing

Each container connected to the bridge network is assigned its own internal IP address. Containers can communicate with each other using these IP addresses.

The default bridge network (docker0) typically uses the 172.17.0.0/16 subnet by default. This means the IP addresses assigned to containers connected to this default bridge network range from 172.17.0.1 to 172.17.255.254.

It's important to note that Docker selects the default subnet from private IP ranges defined by RFC 1918, and it might choose a different range if 172.17.0.0/16 is already in use. However, 172.17.0.0/16 is the most commonly seen default.

You can check the exact subnet and gateway used by your Docker installation with the following command:

docker network inspect bridge --format '{{json .IPAM.Config}}'

This command will give you detailed information about the IP address management (IPAM) configuration for the default bridge network, including the subnet and gateway.

[{"Subnet":"172.17.0.0/16","Gateway":"172.17.0.1"}]

Containers on the bridge network are isolated from the host's network, although the host can communicate with the containers.

Docker uses NAT(Network Address Translation) to manage the container's access to the external network. When a container needs to communicate with the outside world, Docker translates the container's internal IP address to the host's IP address.

Port Mapping and Exposing Ports

By default, containers on a bridge network cannot be accessed from outside the host machine. To enable external access, specific container ports must be exposed and mapped to the host's ports.

This is done using the -p or --publish flag in the docker run command. For example, mapping a container's port 80 to port 8080 on the host is done with -p 8080:80.

docker run -p 8080:80 <your-web-server-image>

DNS and Service Discovery

Containers on the default bridge network can only access each other by IP addresses, unless you use the --link option, which is considered legacy. On a user-defined bridge network, containers can resolve each other by name or alias.

Docker containers use the same DNS servers as the host by default, but you can override this with --dns. This flag specifies the IP address of a DNS server.

By default, containers inherit the DNS settings as defined in the /etc/resolv.conf configuration file. Containers that attach to the default bridge network receive a copy of this file. Containers that attach to a custom network use Docker's embedded DNS server. The embedded DNS server forwards external DNS lookups to the DNS servers configured on the host.

Security and Network Policies

The bridge network is protected by firewall rules that manage and restrict the flow of traffic to and from the containers. On Linux, Docker manipulates iptables rules to provide network isolation.

Users can implement additional network policies for enhanced security. For example, If you're running Docker on a host that is exposed to the Internet, you will probably want to have iptables policies in place that prevent unauthorized access to containers or other services running on your host.

You can add iptables policy before Docker's rules. In general, Docker installs two custom iptables chains named DOCKER-USER and DOCKER, and it ensures that incoming packets are always checked by these two chains first. These chains are part of the FORWARD chain.

All of Docker's iptables rules are added to the DOCKER chain. Do not manipulate this chain manually. If you need to add rules which load before Docker's rules, add them to the DOCKER-USER chain. These rules are applied before any rules Docker creates automatically.

To allow only a specific IP or network to access the containers, insert a negated rule at the top of the DOCKER-USER filter chain. For example, the following rule restricts external access from all IP addresses except 192.168.1.1:

iptables -I DOCKER-USER -i ext_if ! -s 192.168.1.1 -j DROP

Use Cases

Here are several common use cases for the default bridge network:

Remember, the default bridge network is not recommended for production.

1. Development and Testing Environments

  • Isolated Environment: The default bridge network is ideal for development and testing, where you need an isolated network environment to run and interact with your containers without affecting your host network or being affected by it.

  • Multiple Containers: When you are running multiple containers that need to interact with each other (like a web application and a database), the default bridge network allows these containers to communicate seamlessly.

2. Simple Web Applications

  • Single-Host Web Services: For simple web applications running on a single host, the default bridge network is often sufficient. For example, you could run a web server in one container and a database in another, with both containers on the same bridge network.

  • Port Mapping: You can map the ports of these services to the Docker host's ports to make them accessible from outside the host.

3. Running Standalone Containers

  • Single Container Applications: If you have standalone applications that don't need to communicate with other containers or require advanced networking features, the default bridge network provides a simple and quick solution.

4. Legacy Applications

  • Migration to Containers: For legacy applications being migrated into containers, using the default bridge network can be a first step in the process, offering a straightforward method to containerize the application without immediately needing to address complex networking concerns.

5. Network Segmentation

  • Isolation from Host Network: When you need to keep container traffic segmented from your host network for security or organizational reasons, the default bridge network offers this isolation by default.

6. Small Scale Deployments

  • Resource Constraints: In environments with limited resources, such as small servers or personal computers, the default bridge network is a lightweight solution that doesn’t require additional overhead or complex configuration.

While the default bridge network in Docker is not as feature-rich or scalable as user-defined bridge networks or other advanced networking options like overlay networks, it provides a simple, out-of-the-box solution for a variety of basic use cases. It's particularly useful in scenarios where simple networking is sufficient or when starting out with Docker. However, for complex, multi-host, or production environments, more advanced networking options are recommended.

Workshop: Use the default bridge network

Go through the workshop exercise provided by Docker Docs to understand the key features of the default bridge network.

💡
For the testing purposes you can boot up local Ubuntu 20.04 VM with already installed Docker daemon. To boot up the machine use Vagrant. Code files can be found here.
Remember, that Docker uses NAT to enable containers to access the external network. When a container tries to access an external resource (like pinging google.com), Docker translates the container's internal IP address to the host's IP address. It doesn't mean that the container has direct access to the host network. Containers on the default bridge network have their own private internal IP addresses and are isolated from the host’s network.

References:

  1. Networking overview

  2. Bridge network driver

  3. Networking with standalone containers

  4. Bridge networking Lab

  5. Docker Networking Design Philosophy

  6. Docker Networking 101: A Blueprint for Seamless Container Connectivity

  7. Going Behind The Scenes of Docker Networking

  8. Understanding Docker Networking

  9. docker network ls

  10. Packet filtering and firewalls

  11. Overlay network driver

  12. Docker networking YouTube