45 Host, Bridge, Slirp4netns

Container-Netzwerke folgen einem einfachen Grundprinzip: Alles läuft in isolierten Netzwerknamespaces, und der Entwickler entscheidet, wie dieser Namespace an die Außenwelt oder andere Container angeschlossen wird. Podman bietet drei fundamentale Netzwerkmodelle, die für 90 % aller Anwendungsfälle relevant sind: Host, Bridge und Slirp4netns. Jedes Modell adressiert unterschiedliche Anforderungen an Performance, Isolation, Sicherheit und Privilegien – und jedes hat charakteristische Stärken und Schwächen, die man kennen muss, um produktionsnahe Architekturen konsistent zu gestalten.

45.1 Host-Netzwerk: maximale Performance, minimale Isolation

Das Host-Netzwerkmodell ist das radikalste und zugleich einfachste Modell. Der Container erhält keinen eigenen Netzwerknamespace – stattdessen agiert er direkt im Netzwerk des Hosts.

45.1.1 Eigenschaften des Host-Modells

Die fehlende Isolation ist Segen und Fluch. Es eignet sich für:

Im Rootless-Modus ist host networking stark eingeschränkt und oft gar nicht verfügbar, da unprivilegierte Prozesse keinen Zugriff auf den Netzwerknamespace des Hosts erhalten.

Praktischer Hinweis: Host-Netzwerke sind das Netzwerkmodell, das Sicherheitsteams am häufigsten verbieten – aus gutem Grund.

45.2 Bridge-Netzwerk: isoliert, flexibel und der Standardfall

Das Bridge-Modell ist das klassische Container-Netzwerkmodell und heute de facto Standard in Podman-, Docker- und Kubernetes-nahen Architekturen. Jeder Container erhält:

45.2.1 Stärken des Bridge-Netzwerks

Bridge-Netzwerke sind besonders geeignet für serviceorientierte Architekturen:

Die Isolation ist granular und erklärbar – wichtig für Sicherheit, Compliance und reproduzierbare Deployments.

45.2.2 Bridge-Netzwerk im Rootless-Modus

Wenn Podman rootless läuft, kann die Engine keine Kernel-Bridges bauen. Deshalb wird das Bridge-Modell im Hintergrund mit Userspace-Mechanismen simuliert, aber semantisch bleibt es identisch:

Performance ist dabei gut, aber nicht so hoch wie im Root-Modus.

45.3 Slirp4netns: Rootless Networking für alle Fälle

Slirp4netns ist das Kernstück des Rootless-Netzwerkmodells. Da unprivilegierte Nutzer keine Bridging-, NAT- oder Routingoperationen im Kernel durchführen dürfen, übernimmt slirp4netns diese Aufgaben im Userspace.

45.3.1 Eigenschaften von Slirp4netns

Slirp4netns ist ideal für:

Slirp4netns ist bewusst konservativ implementiert. Es garantiert:

45.3.2 Performancecharakteristik

Slirp4netns verursacht zusätzlichen Overhead:

Für produktionsnahe Performance-Benchmarks ist rootless networking kaum geeignet. Für lokale Arbeitsabläufe dagegen ideal.

45.3.3 Portmapping im Slirp-Modell

Da slirp4netns keinen privilegierten Zugriff hat, muss die Engine Portmapping umsetzen:

Wer lokale Entwicklungscontainer startet, merkt davon wenig – außer wenn man traditionelle Ports wie 80 oder 443 nutzen möchte.

45.4 Vergleich der drei Modelle

Ein direkter Vergleich hilft, Architekturentscheidungen zu treffen:

45.4.1 Empfehlung nach Szenario

45.5 Fehlerszenarien

Typische Probleme zeigen sofort, welches Netzwerkmodell im Einsatz ist:

45.5.1 Host-Netzwerk

45.5.2 Bridge-Netzwerk

45.5.3 Slirp4netns