In Kubernetes sind Network Policies das zentrale Mittel, um den Netzwerkverkehr zwischen Pods zu steuern und Security- und Segmentierungsanforderungen umzusetzen. In reinen Docker- oder Docker Compose-Umgebungen fehlt diese native Funktionalität jedoch. Administratoren müssen alternative Strategien einsetzen, um ähnliche Isolation und Traffic-Kontrollen zu erreichen, ohne auf Kubernetes zu setzen. Dieser Artikel zeigt praxisnahe Ansätze für Network Policy Alternativen auf Linux-basierten Container-Hosts.

1. Linux-Firewall Regeln als Basis

Auch ohne Kubernetes kann Linux selbst den Netzwerkverkehr zwischen Containern steuern. Dazu kommen iptables oder nftables zum Einsatz.

Beispiel: Containernetzwerk isolieren mit iptables

# Alle eingehenden Verbindungen auf das interne Netzwerk blocken
iptables -I FORWARD -i br-abcdef123456 -j DROP
Ausgewählte IP-Adressen erlauben
iptables -I FORWARD -i br-abcdef123456 -s 172.18.0.2 -j ACCEPT

iptables -I FORWARD -i br-abcdef123456 -s 172.18.0.3 -j ACCEPT

• br-abcdef123456 ist das Bridge-Netzwerk des Compose Stacks.
• Nur definierte Quell-IP-Adressen dürfen kommunizieren.
• Alle anderen Verbindungen werden standardmäßig geblockt.

2. Docker benutzerdefinierte Netzwerke

Docker unterstützt mehrere Netzwerktreiber, die zur Isolation genutzt werden können. Standardmäßig werden Container im Bridge-Netzwerk gestartet. Durch eigene Netzwerke lässt sich Traffic gezielt segmentieren.

Beispiel: Separate Netzwerke für Microservices

docker network create frontend-net
docker network create backend-net
docker run -d --name web --network frontend-net myapp:latest

docker run -d --name api --network backend-net myapi:latest

• Container im frontend-net kommunizieren nur untereinander.
• Backend-Services sind im backend-net isoliert.
• Cross-Network-Kommunikation erfordert explizite Verbindungen oder Proxies.

3. Reverse Proxy und Service-to-Service Kontrolle

Ein zentraler Reverse Proxy kann Netzwerkzugriffe kontrollieren und als Sicherheitsgateway zwischen Services dienen. So lassen sich Regeln für HTTP/S Traffic einfach durchsetzen.

Beispiel: Nginx für Service-Whitelisting

server {
    listen 80;
location /api {
    allow 172.18.0.2;
    allow 172.18.0.3;
    deny all;
    proxy_pass http://api:8080;
}

}



Nur bestimmte Container-IP-Adressen dürfen den Service ansprechen.
Alle anderen Verbindungen werden abgelehnt.
Rate Limiting und TLS-Termination können hier ebenfalls integriert werden.

4. Macvlan und VLAN-basierte Isolation
Für Szenarien, in denen Container wie physische Hosts behandelt werden sollen, kann Macvlan eingesetzt werden. Dies ermöglicht Layer-2 Isolation und Nutzung separater Subnetze für Container.
Beispiel: Macvlan Netzwerk
docker network create -d macvlan 
  --subnet=192.168.100.0/24 
  --gateway=192.168.100.1 
  -o parent=eth0 macvlan-net
docker run -d --name isolated-container --network macvlan-net myapp:latest




Jeder Container erhält eine eigene IP im Subnetz.
Kommunikation kann über VLAN-Routing oder Firewalls gesteuert werden.
Geeignet für Multi-Tenant Umgebungen.

5. eBPF-basierte Filter
Mit modernen Linux-Kernels können eBPF-Programme zur Laufzeit Netzwerkpakete filtern. Tools wie Cilium oder bpfilter bieten granulare Policy-Kontrolle.
Vorteile von eBPF

Hohe Performance durch Kernel-Level Verarbeitung.
Dynamische Policies ohne Container-Neustart.
Feingranulare Kontrolle auf Port, IP und Service-Level.

6. Host-Firewall + Overlay-Netzwerke
Bei Compose Stacks mit Overlay-Netzen lassen sich Firewall-Regeln direkt auf den Host anwenden:

Filter für docker_gwbridge oder vxlan Interfaces.
Erlauben nur gezielte Ports und IPs für Service-Kommunikation.
Integration in vorhandene IPTables/nftables Policies.

7. Monitoring und Logging
Ohne Kubernetes muss die Netzwerkaktivität überwacht werden, um Policy-Verstöße zu erkennen.

Container Logs konsolidieren.
Netzwerkverkehr mit tcpdump oder Wireshark analysieren.
Automatisierte Alerts bei ungewöhnlichem Traffic implementieren.

8. Best Practices

Container nur in dedizierten Netzwerken betreiben, niemals im Default Bridge.
Minimal erlaubte Ports und IPs definieren.
Reverse Proxy oder API-Gateway als Kontrollpunkt einsetzen.
Firewall- und Overlay-Regeln regelmäßig überprüfen.
Logging und Monitoring frühzeitig einrichten.

Fazit
Auch ohne Kubernetes lassen sich in Docker Compose-Netzwerken Netzwerk-Policies umsetzen. Eine Kombination aus benutzerdefinierten Netzwerken, Firewalls, Reverse Proxies und optional eBPF ermöglicht granulare Kontrolle über den Container-Traffic. Mit konsequentem Monitoring und Logging lassen sich Sicherheitsrichtlinien effektiv durchsetzen, während gleichzeitig Performance und Wartbarkeit erhalten bleiben.
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:


Professionelle Konfiguration von Routern und Switches


Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen


Erstellung von Topologien und Simulationen in Cisco Packet Tracer


Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG


Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible


Erstellung von Skripten für wiederkehrende Netzwerkaufgaben


Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege


Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting


Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.