Docker Macvlan Networks

and other types of Docker network drivers

See further information about Docker networks here: https://docs.docker.com/network/drivers/

In my Docker environment I make use of a few Docker Swarm features and also run Swarm on my single Docker host in preparation so I could add more Docker hosts to the swarm in future. Of the various Docker network types the basic ones are: Bridge and Overlay. Bridge is scoped for use on an individual Docker host (not swarm-aware), while Overlay is swarm-aware.

Docker Network Types

Each type of network is enabled through use of a specific driver, so Docker network types are also referred to as Docker network drivers. Docker provides an excellent summary of each driver on their documentation page (linked above), so I’ll just say what they’ve said. The ones that I typically use are in bold:

  • Bridge: the “default” network type that is good for running most containers, or containers that don’t require special networking capabilities. User-defined bridge networks enable containers on the same Docker host to communicate with each other (network is not swarm-aware). Bridge networks are isolated networks such that all containers attached to it can communicate with each other - useful when needing a common network for all containers in the same “project”. Bridge networks are isolated from the host and require specific port mappings to be “exposed / published”.
  • Host: shares the host’s network with the container. When you use this driver the container’s network isn’t isolated from the host.
  • Overlay: best when you need containers running on different Docker hosts to communicate with each other. Like a Bridge network, but swarm-aware so that swarm services can automatically share the network configuration to all Docker hosts in the swarm. Overlay networks are isolated from their hosts, so they require specific port mappings to be “exposed / published”.
  • MACvlan: good for migrating from a traditional VM environment or when you need your containers to appear like physical hosts on the network. This network type, and the IPvlan type, allows your containers to gain direct access to the network and be managed by traditional network security tools (like firewalls).
  • IPvlan: similar to the MACvlan type but doesn’t assign a unique MAC address to each container. Use this type if there is a restriction on the number of MAC addresses you can assign to a network interface or port on your Docker host (the restriction would likely come from the Docker host’s underlying OS).
  • none: completely isolate a container from the host and other containers. Containers with this network type are not meant to have any network communication, so publishing ports to expose services does not work. This type of network is not available when running a container on a Docker Swarm.

Preference for Docker MACvlan Network Type

In my homelab environment I am the administrator for every aspect of service delivery, including system administration and network administration. Network firewalls are still a recommended security technology for all types of networks, and I certainly run one myself and recommend it for any homelab network. Modern firewalls provide many services useful to a homelab network, not least of which is a firewall’s primary function - the list of traffic forwarding rules. Since firewall rules are still based on where traffic came from and which interface, IP address, or port that it wants to go to, managing network traffic destined for containers can become messy with each container using the Docker host’s IP address. Using MACvlan networks to make containers “first class citizens” on the network means firewall management becomes more organized. Each Docker MACvlan network is its own VLAN and thus is a separate interface in the firewall, which simply enhances the organization of firewall rules. There are security considerations as well, especially for environments where traditional VMs and containers operate side-by-side.

For a more complete discussion of network security practices for Docker MACvlan containers and subnet separation, please see my article (Network Security Through Subnet Separation) on the topic