Kubernetes Network Policy erklärt

Eine Kubernetes Network Policy legt fest, welcher Netzwerkverkehr zwischen Pods, Namespaces und dem Rest der Welt erlaubt ist. Ohne sie kann in den meisten Clustern jeder Pod jeden anderen Pod erreichen, unabhängig davon, ob das nötig ist. Mit einer Network Policy beschränkst du das gezielt auf genau die Verbindungen, die deine Anwendung tatsächlich braucht.

Ich betreibe Kubernetes-Cluster in Produktion und habe die Netzwerksegmentierung dort selbst über Jahre schrittweise eingeführt, mit allen Stolperfallen, die dabei auftauchen. Alle meine Beiträge zu Kubernetes findest du gesammelt auf der Seite Kubernetes.

Was eine Kubernetes Network Policy regelt

Eine Network Policy ist ein eigenes Kubernetes-Objekt, das für einen oder mehrere Pods festlegt, welcher eingehende (Ingress) und ausgehende (Egress) Verkehr erlaubt ist. Sie wirkt wie eine Firewall auf Ebene des Pods, nicht auf Ebene der Node oder des ganzen Clusters. Eine Regel gilt immer nur für die Pods, die ihr podSelector trifft, alle anderen Pods bleiben davon unberührt.

Wichtig dabei: Network Policies sind additiv. Treffen mehrere Regeln auf denselben Pod zu, gilt die Vereinigung aller erlaubten Verbindungen, keine Regel kann eine andere wieder einschränken. Das unterscheidet die Network Policy deutlich von RBAC, wo eine fehlende Berechtigung automatisch zu einer Ablehnung führt. Bei Netzwerkregeln musst du selbst dafür sorgen, dass am Ende nur das erlaubt ist, was du wirklich erlauben willst.

Ohne Network Policy: warum jeder Pod mit jedem sprechen darf

In einem frisch aufgesetzten Cluster gibt es standardmäßig keine Einschränkung: Jeder Pod kann jeden anderen Pod über dessen IP-Adresse erreichen, über Namespace-Grenzen hinweg. Das ist praktisch für den Einstieg, aber in Produktion ein Risiko. Wird ein einzelner Pod kompromittiert, kann er ungehindert versuchen, sich zu Datenbanken, internen APIs oder anderen Namespaces zu verbinden.

Genau hier setzt die Network Policy an, als Ergänzung zu RBAC und Pod Security Standards. Während RBAC regelt, wer über die Kubernetes-API Objekte anlegen darf, und Pod Security Standards regeln, wie ein Pod selbst konfiguriert sein darf, regelt die Network Policy, mit wem ein laufender Pod im Netzwerk sprechen darf. Wie diese drei Ebenen zusammenspielen, zeige ich auch in Pod Security Standards in Kubernetes.

Default-Deny als Ausgangspunkt

Die gängigste Empfehlung für den Einstieg lautet, zuerst jeglichen Verkehr in einem Namespace zu blockieren und danach gezielt zu erlauben, was gebraucht wird. Dieses Default-Deny-Muster ist der sicherste Ausgangspunkt, weil du danach nur noch Ausnahmen hinzufügen musst, statt nachträglich Löcher in eine offene Konfiguration zu stopfen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: shop
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Ein leerer podSelector trifft alle Pods im Namespace shop. Da unter spec weder ingress noch egress mit Regeln gefüllt sind, die beiden Richtungen aber unter policyTypes aktiv geschaltet werden, blockiert diese Policy jeglichen eingehenden und ausgehenden Verkehr für alle Pods im Namespace. Von hier aus fügst du für jede Anwendung gezielt die Verbindungen hinzu, die sie tatsächlich braucht.

Namespace- und Pod-Selektoren: Traffic gezielt erlauben

Nach dem Default-Deny brauchst du Regeln, die genau die Verbindungen wieder öffnen, die deine Anwendung braucht. Dafür stehen dir zwei Selektoren zur Verfügung, die du auch kombinieren kannst: der podSelector wählt Pods anhand ihrer Labels aus, der namespaceSelector wählt ganze Namespaces anhand ihrer Labels aus.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-erlaubt-von-frontend
  namespace: shop
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Diese Regel erlaubt eingehenden Verkehr auf Port 8080 zu allen Pods mit dem Label app: api, aber nur von Pods mit dem Label app: frontend im selben Namespace. Willst du denselben Zugriff auch aus einem anderen Namespace erlauben, kombinierst du podSelector und namespaceSelector innerhalb desselben from-Eintrags, dann müssen beide Bedingungen gleichzeitig zutreffen. Getrennte Einträge in der from-Liste wirken dagegen wie ein logisches Oder.

Egress-Regeln und die DNS-Ausnahme, die oft vergessen wird

Ausgehender Verkehr wird beim Einstieg gern übersehen, weil eine Anwendung ohne Egress-Regeln zwar keine Verbindungen mehr aufbauen kann, aber selbst dann noch fehlerfrei zu starten scheint, solange sie nicht wirklich etwas anfragt. Sobald du Egress mit policyTypes: [Egress] einschränkst, brauchst du mindestens eine Regel, die den DNS-Zugriff erlaubt, sonst kann der Pod nicht einmal Servicenamen auflösen.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: egress-dns-erlaubt
  namespace: shop
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Diese Regel erlaubt allen Pods im Namespace ausgehende Verbindungen zu den DNS-Pods des Clusters auf Port 53, sowohl über UDP als auch über TCP. Fehlt diese Ausnahme, scheitern Anwendungen oft an schwer zu deutenden Timeouts, weil schon die Namensauflösung für einen internen Service nicht funktioniert. Für Verkehr nach außerhalb des Clusters, etwa zu einer externen API, ergänzt du zusätzlich eine Regel mit ipBlock und dem passenden CIDR-Bereich.

Voraussetzung: die CNI muss Network Policies unterstützen

Eine Network Policy ist nur eine Beschreibung, umgesetzt wird sie vom Netzwerk-Plugin deines Clusters, dem Container Network Interface (CNI). Nicht jede CNI kann das. Legst du eine Network Policy in einem Cluster an, dessen CNI sie ignoriert, wird das Objekt anstandslos angenommen, aber nie durchgesetzt, ein gefährlicher stiller Fehlschlag.

CNI-Plugin	Network Policies
Flannel (Standardkonfiguration)	setzt selbst keine durch
Calico	unterstützt
Cilium	unterstützt, zusätzlich eigene erweiterte Regeln
Antrea	unterstützt, dazu eigene clusterweite Policies

Bevor du eine Default-Deny-Regel produktiv ausrollst, prüfe deshalb, welche CNI dein Cluster tatsächlich einsetzt. k3s ist dabei ein Sonderfall, den viele falsch einschätzen: Es liefert Flannel als CNI aus, startet aber zusätzlich einen eingebetteten kube-router-Netzwerkpolicy-Controller, der die Regeln durchsetzt (k3s-Dokumentation zu Netzwerkdiensten). Genau so laufen meine Cluster, im k3s-Standardsetup, und ich nutze Network Policies dort vor allem, um Kundensysteme voneinander zu trennen. Die vollständige Referenz zu Feldern und Verhalten liefert die Kubernetes-Dokumentation zu Network Policies.

Häufige Fragen

Was ist die Kubernetes Network Policy Deny All Regel?

Das ist die gängige Bezeichnung für eine Policy mit leerem podSelector und beiden Einträgen in policyTypes, aber ohne definierte Regeln unter ingress oder egress. Sie blockiert jeglichen Verkehr für alle Pods im Namespace und ist meist der erste Schritt, bevor gezielt Ausnahmen ergänzt werden.

Wie funktioniert Kubernetes Network Policy Egress in der Praxis?

Egress-Regeln erlauben ausgehenden Verkehr aus einem Pod heraus, ausgewählt über Ziel-Pods, Ziel-Namespaces oder IP-Bereiche, jeweils mit den erlaubten Ports. Ohne mindestens eine Egress-Regel für DNS auf Port 53 kann ein Pod, dessen Egress eingeschränkt ist, meist nicht einmal interne Servicenamen auflösen.

Was zählt zu den Kubernetes Network Policy Best Practices?

Aus meiner Erfahrung: mit einer Default-Deny-Regel je Namespace beginnen, danach Zugriffe möglichst eng über Labels statt über ganze Namespaces öffnen, die DNS-Ausnahme nie vergessen und jede neue Regel zuerst in einem Testcluster mit derselben CNI ausprobieren, bevor sie in Produktion geht.

Reicht eine Network Policy als alleinige Absicherung des Clusters?

Nein. Eine Network Policy regelt nur den Netzwerkverkehr zwischen Pods. Wer über die API Objekte anlegen darf, regelt RBAC, wie ein Pod konfiguriert sein muss, regeln Pod Security Standards und zusätzliche Admission-Policies. Alle drei Ebenen ergänzen sich und ersetzen sich nicht gegenseitig.

Wie du weitermachst

Die Network Policy ist die Netzwerkseite einer Absicherung, die mit sauber geschnittenen Namespaces beginnt, wie ich sie in Kubernetes Namespaces richtig nutzen beschreibe, und mit stabilen Service-Adressen arbeitet, wie in Kubernetes Service Types erklärt. Die Absicherung des einzelnen Pods selbst behandle ich in Pod Security Standards in Kubernetes.

Mein Vorschlag für den Einstieg: Prüfe zuerst, welche CNI dein Cluster nutzt, lege dann in einem unkritischen Namespace eine Default-Deny-Regel an und beobachte, welche Verbindungen tatsächlich fehlschlagen, bevor du produktive Namespaces umstellst.

Mein Kubernetes-Praxisbuch bei Rheinwerk widmet Kapitel 7 der Governance und Security in Kubernetes, mit eigenen Abschnitten zu RBAC und Policies. Die Network Policy selbst behandle ich dort nicht, sie gehört technisch eng zur CNI-Wahl deines Clusters und damit eher zur Netzwerkschicht als zur klassischen Policy-Engine. Alle Informationen zum Buch findest du auf meiner Kubernetes-Seite.