Eine Kubernetes NetworkPolicy ist eine Firewall-Regel für Pods: Sie legt fest, welche Pods mit welchen anderen Pods über das Netzwerk kommunizieren dürfen. Ohne NetworkPolicy ist in Kubernetes standardmäßig der gesamte Datenverkehr zwischen Pods erlaubt – das Cluster-Netzwerk ist „flach“.
Aufbau einer NetworkPolicy
Eine NetworkPolicy arbeitet mit drei Bausteinen:
- podSelector: wählt die betroffenen Pods über Labels aus (z. B.
app: web). Ein leeres ObjektpodSelector: {}trifft alle Pods im Namespace. - policyTypes: legt fest, ob Ingress (eingehend), Egress (ausgehend) oder beide Richtungen geregelt werden.
- Regeln: erlauben Datenverkehr von oder zu bestimmten Quellen und Zielen – per
podSelector,namespaceSelectoroderipBlock, eingeschränkt auf einzelneports.
Default-Deny-Muster
Ein bewährtes Zero-Trust-Muster ist Default-Deny: Zuerst eine Policy mit leerem podSelector und den Typen Ingress und Egress anlegen, die allen Pods im Namespace jeglichen Verkehr verbietet, und danach gezielt die erlaubten Verbindungen freischalten.
Wichtig: Eine Egress-Sperre blockiert auch DNS-Antworten. Wer ausgehenden Verkehr einschränkt, muss eine separate Egress-Regel für den Cluster-DNS-Dienst (kube-dns beziehungsweise CoreDNS) ergänzen, sonst funktioniert die Namensauflösung nicht mehr.
Voraussetzungen und Einsatz
NetworkPolicies werden vom CNI-Plugin des Clusters umgesetzt – Calico und Cilium unterstützen sie, einfachere CNIs wie Flannel nicht. Netzwerk-Segmentierung, Microservice-Isolation und Compliance sind typische Anwendungsfälle. Die Netzwerk-Segmentierung ist Teil einer mehrschichtigen Härtung: Die Kubernetes Pod Security schränkt ergänzend die Sicherheitsanforderungen der Pods selbst ein.
Verwandte Grundlagen: Kubernetes, Pod, Kubernetes Selector, CNI, Calico, Cilium, Namespace. Externen Datenverkehr steuert die Kubernetes Gateway API; die Verfügbarkeit der geschützten Pods sichert ein PodDisruptionBudget.