Eigene Bridge-Netzwerke für Container-Isolation

1. Warum die Default-Bridge nicht ausreicht

Jeder frisch installierte Docker-Host bringt ein Netzwerk namens bridge mit, das jedem Container ohne explizite Angabe automatisch zugewiesen wird. Auf den ersten Blick funktioniert das: Container bekommen eine IP-Adresse, können ins Internet und untereinander per IP kommunizieren. Genau hier liegt aber das Problem für alle, die mehr als ein oder zwei Container betreiben. Ein Bridge-Netzwerk in der Default-Konfiguration bietet keine automatische Namensauflösung zwischen Containern, das heißt jede Verbindung muss über die IP-Adresse laufen, die sich bei jedem Neustart ändern kann.

Noch gravierender ist die fehlende Isolation. Startet man auf demselben Host ein Projekt A und ein Projekt B ohne eigenes Bridge-Netzwerk, landen alle Container im selben Default-Segment und können sich gegenseitig erreichen, selbst wenn das fachlich nie gewollt war. Ein kompromittierter Container aus Projekt A hätte damit direkten Netzwerkzugriff auf die Datenbank von Projekt B. Ein eigenes Bridge-Netzwerk pro Projekt oder pro Umgebung schließt diese Lücke, weil Docker Container in unterschiedlichen Netzwerken standardmäßig voneinander trennt, sofern sie nicht explizit demselben Netzwerk beitreten.

2. Docker-Netzwerktreiber im Überblick

Docker bringt mehrere Netzwerktreiber mit, und ein Bridge-Netzwerk ist dabei der Standardfall für alles, was auf einem einzelnen Host läuft. Der bridge-Treiber erstellt eine virtuelle Netzwerkbrücke im Linux-Kernel, an die jeder Container über ein virtuelles Ethernet-Paar angeschlossen wird. Der host-Treiber verzichtet komplett auf Isolation und teilt den Netzwerk-Namespace des Hosts direkt mit dem Container, was Performance-Vorteile bringt, aber jede Portzuordnung unmöglich macht, weil der Container direkt auf den Host-Ports lauscht.

Für Multi-Host-Szenarien existiert der overlay-Treiber, der Container über mehrere Docker-Hosts hinweg in einem virtuellen Netzwerk verbindet, meist im Kontext von Docker Swarm. Der macvlan-Treiber weist Containern eigene MAC-Adressen im physischen LAN zu, sodass sie wie eigenständige Geräte im Netzwerk erscheinen. Für die meisten Projekte auf einem einzelnen Server oder einer einzelnen Entwicklungsmaschine bleibt das Bridge-Netzwerk aber die richtige Wahl, weil es die beste Balance aus Isolation, Konfigurierbarkeit und Einfachheit bietet.

# List all networks including the default bridge, host and none
docker network ls

# Inspect the driver, subnet and connected containers of a network
docker network inspect bridge

# Show only the driver column for a quick overview
docker network ls --format '{{.Name}}: {{.Driver}}'

3. Ein eigenes Bridge-Netzwerk anlegen und nutzen

Ein eigenes Bridge-Netzwerk anzulegen ist ein einzeiliger Befehl. Wichtig ist, den Namen sprechend zu wählen, damit auf einem Host mit mehreren Projekten sofort erkennbar bleibt, welches Netzwerk zu welcher Anwendung gehört. Nach der Erstellung wird das Netzwerk beim Start eines Containers über --network zugewiesen, alternativ kann ein bereits laufender Container nachträglich mit docker network connect hinzugefügt werden, ohne ihn neu zu starten.

Ein Container kann gleichzeitig Mitglied mehrerer Netzwerke sein, etwa ein Reverse Proxy, der sowohl im öffentlichen Netzwerk als auch in mehreren internen Anwendungsnetzwerken hängt. Das ist ein häufiges Muster, um genau einen Zugangspunkt zu definieren, während die dahinterliegenden Dienste in getrennten Bridge-Netzwerken voneinander isoliert bleiben. Wer ein Netzwerk wieder entfernen will, muss zuerst alle verbundenen Container trennen oder stoppen, Docker verweigert sonst das Löschen mit einer klaren Fehlermeldung.

# Create a dedicated bridge network for one project
docker network create shop-network

# Start a container attached to that network directly
docker run -d --name shop-db --network shop-network mysql:8.0

# Attach an already running container to an additional network
docker network connect shop-network shop-cache

# Detach a container from a network without stopping it
docker network disconnect shop-network shop-cache

# Remove an unused network
docker network rm shop-network

4. Eingebauter DNS und Service Discovery

Der entscheidende Vorteil eines benutzerdefinierten Bridge-Netzwerks gegenüber der Default-Bridge ist die eingebaute Namensauflösung. Sobald zwei Container demselben benutzerdefinierten Netzwerk beitreten, können sie sich gegenseitig über den Containernamen erreichen, ganz ohne manuelle Konfiguration. Docker betreibt dafür einen eingebetteten DNS-Server unter der Adresse 127.0.0.11 innerhalb jedes Containers, der Containernamen und in Compose zusätzlich Servicenamen zu den jeweiligen IP-Adressen auflöst.

Das bedeutet in der Praxis: eine Anwendung, die auf shop-db:3306 statt auf eine feste IP zugreift, funktioniert auch dann weiter, wenn der Datenbankcontainer neu gestartet wird und dabei eine neue IP-Adresse erhält. Diese Namensauflösung ist der Hauptgrund, warum Teams grundsätzlich benutzerdefinierte Bridge-Netzwerke statt der Default-Bridge verwenden sollten, selbst wenn nur zwei Container beteiligt sind. Aliasnamen lassen sich zusätzlich über --network-alias vergeben, sodass ein Container unter mehreren Namen gleichzeitig erreichbar ist, etwa während einer Migration von einem alten auf einen neuen Servicenamen.

5. Mehrere Bridge-Netzwerke zur Segmentierung

Mit mehreren Bridge-Netzwerken lässt sich eine Anwendung in klar getrennte Zonen aufteilen. Ein typisches Muster für einen Onlineshop: ein Frontend-Netzwerk, dem nur Webserver und Reverse Proxy angehören, ein Backend-Netzwerk mit Anwendungscontainern und ein Datenbank-Netzwerk, dem ausschließlich die Datenbank und die Anwendungscontainer angehören, nicht aber der Webserver. Der Webserver hat damit gar keine Netzwerkroute zur Datenbank, selbst wenn er kompromittiert würde.

Diese Segmentierung über getrennte Bridge-Netzwerke ist deutlich einfacher umzusetzen als klassische Firewall-Regeln, weil Docker die Trennung von Haus aus durchsetzt, ohne dass iptables-Regeln manuell gepflegt werden müssen. Wichtig dabei: jeder Container, der in mehreren Zonen kommunizieren muss, etwa der Anwendungscontainer zwischen Backend- und Datenbank-Netzwerk, wird einfach beiden Netzwerken zugewiesen. Docker verwaltet die zugehörigen Routen automatisch über die jeweilige Netzwerkbrücke im Kernel.

6. Internes Netzwerk ohne Internetzugriff

Für besonders sensible Dienste wie eine Datenbank oder einen internen Cache lässt sich ein Bridge-Netzwerk mit dem Flag --internal erstellen. Docker richtet dann keine Route über das externe Interface des Hosts ein, sodass Container in diesem Netzwerk weder ausgehende Verbindungen ins Internet aufbauen noch von außen erreichbar sind. Selbst wenn ein Angreifer Code innerhalb eines solchen Containers ausführen könnte, bliebe der Container ohne Weg nach draußen, was Datenexfiltration deutlich erschwert.

Der Kompromiss: Container in einem internen Bridge-Netzwerk können auch keine Paketupdates oder externe API-Aufrufe durchführen, was für eine Datenbank meist unproblematisch, für einen Anwendungscontainer mit externen Abhängigkeiten aber ungeeignet ist. Das übliche Muster ist deshalb eine Kombination: ein internes Netzwerk für Datenbank und Cache, ein normales Bridge-Netzwerk für die Anwendungsschicht, verbunden über einen Anwendungscontainer, der in beiden Netzwerken Mitglied ist.

# Create an internal network with no route to the outside world
docker network create --internal db-internal

# Attach the database container only to the internal network
docker run -d --name shop-db --network db-internal mysql:8.0

# Verify: this container has no default route to the internet
docker run --rm --network db-internal alpine \
  sh -c "ping -c 1 -W 2 1.1.1.1 || echo 'no route to internet, as expected'"

7. Subnetze, Gateways und feste IP-Adressen

Standardmäßig wählt Docker beim Anlegen eines Bridge-Netzwerks automatisch ein freies Subnetz aus einem privaten Adressbereich. In Umgebungen mit vielen Netzwerken oder bei Überschneidungen mit dem Firmennetz ist es sinnvoll, Subnetz und Gateway explizit vorzugeben. Das verhindert Adresskonflikte und macht die Netzwerktopologie in der Dokumentation nachvollziehbar, weil jedes Projekt ein festes, bekanntes Subnetz erhält.

Feste IP-Adressen innerhalb eines Bridge-Netzwerks sind in den meisten Fällen unnötig, weil die DNS-basierte Namensauflösung das eigentliche Problem bereits löst. Es gibt aber Ausnahmen: Legacy-Anwendungen, die IP-Adressen fest in einer Konfigurationsdatei hinterlegen, oder Monitoring-Systeme, die per IP statt per Namen abfragen. Für solche Fälle lässt sich einem Container beim Start eine feste IP aus dem definierten Subnetz zuweisen, die bei jedem Neustart erhalten bleibt.

# Create a bridge network with an explicit subnet and gateway
docker network create \
  --driver bridge \
  --subnet 172.28.0.0/16 \
  --gateway 172.28.0.1 \
  shop-network

# Start a container with a fixed IP address inside that subnet
docker run -d --name shop-db \
  --network shop-network \
  --ip 172.28.0.10 \
  mysql:8.0

8. Netzwerke in Docker Compose konfigurieren

In Docker Compose entsteht ein Bridge-Netzwerk automatisch für jedes Projekt, benannt nach dem Projektverzeichnis. Für die im vorherigen Abschnitt beschriebene Segmentierung lassen sich zusätzliche, benannte Netzwerke im networks-Abschnitt der Compose-Datei definieren und Services gezielt zuweisen. Das erlaubt, im selben Compose-Projekt mehrere Bridge-Netzwerke zu kombinieren, etwa ein internes und ein öffentliches, ohne für jedes Netzwerk eine eigene Compose-Datei zu pflegen.

Ein Service, der keine networks-Angabe hat, wird automatisch dem Default-Netzwerk des Compose-Projekts zugewiesen. Wer die Segmentierung ernst nimmt, sollte jedem Service explizit die passenden Netzwerke zuweisen, statt sich auf das automatisch erzeugte Default-Netzwerk zu verlassen, weil dieses Verhalten sonst leicht übersehen wird und ungewollt alle Services zusammenführt.

services:
  proxy:
    image: nginx:alpine
    networks:
      - frontend

  app:
    image: shop-app:latest
    networks:
      - frontend
      - backend

  db:
    image: mysql:8.0
    networks:
      - backend

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true

9. Default-Bridge, Bridge-Netzwerk und Host-Netzwerk im Vergleich

Die Wahl zwischen Default-Bridge, benutzerdefiniertem Bridge-Netzwerk und Host-Netzwerk hat direkte Auswirkungen auf Isolation, DNS-Auflösung und Portverwaltung. Die folgende Tabelle fasst die wichtigsten Unterschiede zusammen, die bei der Netzwerkarchitektur eines neuen Projekts entscheidungsrelevant sind.

In der Praxis zeigt diese Gegenüberstellung, warum die Default-Bridge nach der ersten Testphase eines Projekts kaum noch eine gute Wahl ist. Ein Bridge-Netzwerk pro Projekt, ergänzt um interne Netzwerke für sensible Dienste, deckt die meisten Anforderungen an Namensauflösung und Isolation ab, ohne die Komplexität von Overlay-Netzwerken oder Macvlan-Konfigurationen zu benötigen.

10. Zusammenfassung

Ein eigenes Bridge-Netzwerk pro Projekt ist der einfachste Hebel, um Docker-Container voneinander zu isolieren und gleichzeitig komfortable Namensauflösung zu erhalten. Statt IP-Adressen zu verwalten, sprechen Container einander über Container- oder Servicenamen an, während der eingebettete DNS-Server unter 127.0.0.11 die Auflösung übernimmt. Mit mehreren Bridge-Netzwerken lässt sich eine Anwendung in Frontend-, Backend- und Datenbankzonen segmentieren, ohne dass ein kompromittierter Webserver automatisch Zugriff auf die Datenbank hätte.

Das Flag --internal ergänzt diesen Ansatz für besonders sensible Dienste, indem es jede Route ins Internet unterbindet. Feste Subnetze und IP-Adressen bleiben die Ausnahme für Legacy-Fälle, während die meisten modernen Anwendungen von der automatischen Namensauflösung eines Bridge-Netzwerks profitieren. Wer diese Grundlagen in Docker Compose konsequent über den networks-Abschnitt abbildet, erhält eine nachvollziehbare, dokumentierte Netzwerktopologie statt einer zufällig gewachsenen Default-Bridge mit allen Containern in einem Segment.

11. FAQ: Eigene Bridge-Netzwerke für Container-Isolation