Kubernetes Network Policy: so trennt ihr den Pod-Traffic, bevor der Auditor danach fragt
In Kubernetes ist Netzwerk-Traffic ohne Network Policies vollständig offen: jeder Pod erreicht jeden anderen Pod, über alle Namespaces hinweg. Eine Network Policy ist ein Kubernetes-Objekt, das Ingress- und Egress-Verbindungen auf Label-Ebene erlaubt. Wirksam wird sie nur, wenn euer CNI sie durchsetzt - Cilium und Calico tun das, Flannel nicht. Der übliche Weg: pro Namespace Default-Deny setzen, dann die tatsächlich benötigten Verbindungen einzeln freigeben.
Was ist eine Kubernetes Network Policy?
Eine Kubernetes Network Policy ist ein Objekt im jeweiligen Namespace, das festlegt, wer eine Gruppe von Pods erreichen darf und wohin diese Pods selbst verbinden dürfen. Ausgewählt wird über Labels, nicht über IP-Adressen: der Pod-Selector bestimmt, für welche Pods die Regel gilt, Ingress-Regeln beschreiben eingehende, Egress-Regeln ausgehende Verbindungen.
Die Logik ist additiv und kennt kein Deny. Sobald mindestens eine Policy einen Pod in einer Richtung trifft, gilt für diese Richtung: erlaubt ist nur, was irgendeine Policy ausdrücklich erlaubt. Trifft ihn keine, bleibt er vollständig offen. Genau daraus entsteht das Default-Deny-Muster - eine Policy mit leerem Pod-Selector, die nichts erlaubt, und darauf aufbauend die Freigaben.
Warum im frischen Cluster jeder Pod mit jedem reden darf
Das ist kein Konfigurationsfehler, sondern Absicht. Das Kubernetes-Netzwerkmodell verlangt, dass jeder Pod jeden anderen Pod ohne NAT erreichen kann. Ein CNI, das diese Bedingung nicht erfüllt, wäre nicht konform. Segmentierung ist ein Opt-in, das ihr aktiv anlegen müsst.
Praktisch heißt das: ein Test-Pod im Namespace dev, den vor zwei Jahren jemand für einen Import gebaut hat, erreicht den Datenbank-Service in prod auf Port 5432. Wer einen einzigen Pod übernimmt, steht damit im gesamten internen Netz. Der Ost-West-Traffic ist die Fläche, die klassische Perimeter-Firewalls nicht sehen, weil er den Cluster nie verlässt.
Der Nord-Süd-Weg ist meist sauber abgesichert. Auffällig wird fast immer der Ost-West-Traffic, den niemand je aufgeschrieben hat.
Was im Audit auffällt, wenn keine Network Policy existiert
Der CIS-Benchmark für Kubernetes verlangt in seinem Abschnitt zu Netzwerkrichtlinien, dass in jedem Namespace eine Network Policy definiert ist. Das ist ein Binär-Befund: entweder das Objekt existiert oder nicht. Ein leerer Cluster produziert diesen Befund für jeden einzelnen Namespace, inklusive der System-Namespaces.
Der zweite Befund entsteht im Gespräch. Auditoren fragen nicht nach YAML, sie fragen nach der Begründung: welche Verbindungen zwischen euren Anwendungen sind fachlich nötig, und wer hat das freigegeben. Wenn die Antwort lautet „alle, weil es so voreingestellt ist“, ist das keine Risikoentscheidung, sondern eine ausgelassene. Mehr dazu auf unserer Seite zu Kubernetes Compliance und Nachweisführung.
Wie eine Network Policy wirkt: Labels, Ingress, Egress
Drei Dinge entscheiden, ob eine Regel greift. Erstens der Pod-Selector: er wählt die Pods aus, für die die Policy gilt. Zweitens die Richtung: Ingress und Egress werden getrennt behandelt, eine Policy nur für Ingress lässt ausgehenden Traffic unberührt. Drittens die Quelle oder das Ziel: erlaubt werden andere Pods per Label, ganze Namespaces per Namespace-Selector oder IP-Bereiche per CIDR-Block.
Zwei Fallen sind häufig. Ein Namespace-Selector trifft nur, wenn der Ziel-Namespace passende Labels trägt - viele Cluster haben außer dem automatischen Namensschild gar keine. Und Regeln für Ziele außerhalb des Clusters arbeiten mit IP-Bereichen, nicht mit Hostnamen. Ein Egress auf eine externe API bedeutet in der Standard-API also: IP-Liste pflegen. Für DNS-Namen braucht ihr eine CRD.
Wovon eine Network Policy nichts weiß: Verschlüsselung. Sie regelt, ob eine Verbindung zustande kommt. Ein Service Mesh mit mTLS regelt, wie sie abgesichert ist. Das eine ersetzt das andere nicht.
Welches CNI setzt Network Policies wirklich durch?
Die NetworkPolicy-API ist Teil von Kubernetes, die Durchsetzung ist es nicht. Der API-Server nimmt jedes gültige Manifest an, auch wenn im Cluster niemand es umsetzt. Das ist der gefährlichste Zustand: Regeln sind dokumentiert, im Git-Repo sichtbar, und wirken nicht. Prüft deshalb zuerst, welches CNI läuft, und erst danach eure Regeln.
| CNI | Setzt die Standard-NetworkPolicy-API durch | Eigene CRD für cluster-weite Regeln | Filterebene | Egress auf DNS-Namen | Flow-Logs vor dem Default-Deny |
|---|---|---|---|---|---|
| Cilium | ja | CiliumClusterwideNetworkPolicy | L3-L4 und L7 HTTP | ja | ja, über Hubble |
| Calico | ja | GlobalNetworkPolicy | L3-L4, L7 nur mit Zusatzkomponente | nur in der kommerziellen Variante | eingeschränkt im Open-Source-Umfang |
| Antrea | ja | ClusterNetworkPolicy | L3-L4 und L7 HTTP | ja | ja, über den Flow-Exporter |
| Weave Net | ja | keine | L3-L4 | nein | nein |
| Flannel | nein, nur mit Zusatzkomponente | keine | L3-L4 über die Zusatzkomponente | nein | nein |
| AWS VPC CNI | ja, nur mit aktiviertem Network-Policy-Agent | keine | L3-L4 | nein | ja, Policy-Entscheidungs-Logs |
| Azure CNI | ja, nur wenn beim Cluster-Bau eine Policy-Engine gewählt wurde | keine eigene | L3-L4 | nein | nein, nur Metriken |
Einzelne Zellen ändern sich mit jedem Minor-Release, deshalb notieren wir im Bericht die Version, die in eurem Cluster tatsächlich läuft. Zwei Zeilen verdienen einen Hinweis: Flannel allein ignoriert Network Policies stillschweigend, und Weave Net wird seit dem Ende von Weaveworks 2024 nicht mehr kommerziell gepflegt.
Cilium Network Policy oder Standard-API: wann braucht ihr eine CRD?
Startet mit der Standard-API. Sie deckt L3 und L4 ab, also Pods, Namespaces und Ports, und sie bleibt portabel: wenn ihr in zwei Jahren das CNI wechselt, ziehen die Regeln mit um. Eine CiliumNetworkPolicy oder eine Calico GlobalNetworkPolicy tut das nicht.
Zu einer CRD greift ihr, wenn eine konkrete Anforderung sich anders nicht abbilden lässt. Drei Gründe tragen: cluster-weite Regeln, die auch für morgen angelegte Namespaces gelten; Egress auf einen DNS-Namen statt auf eine IP-Liste, etwa für eine externe API mit wechselnden Adressen; und Filterung auf HTTP-Methoden oder Pfade. Alles andere geht mit dem Standard.
Wie ihr Default-Deny einführt, ohne die Anwendung zu zerlegen
Nicht mit einem großen Rollout, sondern Namespace für Namespace. Die Reihenfolge ist wichtiger als die Geschwindigkeit.
CNI feststellen. Welches Plugin läuft, in welcher Version, und ist die Durchsetzung überhaupt aktiviert. Bei Managed-Clustern hängt das oft an einer Einstellung aus dem Cluster-Bau.
Traffic beobachten. Flow-Logs des CNI einschalten oder eine Policy im Audit-Modus fahren, mindestens eine volle Woche. Kürzer geht nicht, weil Wöchentliches sonst durchrutscht.
Allow-Regeln schreiben. Genau für die beobachteten Verbindungen, nicht für die geplanten. Die DNS-Regel gehört in dieselbe Policy, nicht in eine spätere.
Default-Deny im unkritischen Namespace. Ein voller Werktag Beobachtung, inklusive Nacht-Jobs und Cronjobs, bevor der nächste Namespace folgt.
Namespace für Namespace nachziehen. Produktion zuletzt, mit einem Rollback, der aus einem einzigen Löschvorgang besteht.
In die Vorlage schreiben. Default-Deny gehört in die Namespace-Vorlage eures GitOps-Repos. Sonst kommt der nächste Namespace wieder offen auf die Welt.
Wenn den laufenden Betrieb danach jemand halten soll: das ist der Punkt, an dem unser Managed Kubernetes Service ansetzt. Ein Senior-Engineer betreut 30 bis 50 Cluster mit GitOps, weil die Regeln versioniert im Repo liegen und nicht in einer Konsole.
Woran Network Policies in der Praxis scheitern
Vier Muster sehen wir immer wieder.
DNS vergessen. Ein Default-Deny auf Egress blockiert auch die Anfragen an CoreDNS. Die Anwendung meldet dann Namensauflösungs-Fehler statt Verbindungsfehler, und das Team sucht im falschen Layer.
Labels stimmen nicht. Der Pod-Selector trifft nichts, die Policy gilt für null Pods und fällt niemandem auf, weil kein Fehler entsteht.
Namespaces ohne Labels. Namespace-Selectoren laufen ins Leere, wenn der Ziel-Namespace keine Labels trägt.
Health-Checks und Metriken. Ingress-Controller, Prometheus-Scrapes und Kubelet-Probes brauchen eigene Freigaben. Sie fallen erst beim nächsten Deployment auf, nicht sofort.
Der gemeinsame Nenner: Network Policies scheitern still. Es gibt keine Fehlermeldung für eine Regel, die nichts tut. Deshalb gehört zu jeder Einführung ein Test aus einem Debug-Pod, der beweist, dass die verbotene Verbindung wirklich fällt.
Was der Angriffsflächen-Check ab 850 EUR an eurem Cluster-Netz prüft
Wir haben 17 Anbieter im deutschsprachigen Kubernetes-Security-Umfeld angesehen: 0 von 17 haben ein buchbares Security-Produkt mit Preis. Die SERP zu diesem Thema besteht nach der Kubernetes-Doku fast nur aus Anbieter-Blogs - Inhalt ohne Angebot. Deshalb steht der Preis hier.
Im Angriffsflächen-Check lesen wir in 0,5 bis 1 Personentag eure Manifeste, die vorhandenen NetworkPolicy-Objekte und die CNI-Konfiguration und gleichen sie gegen den CIS-Benchmark ab. Ihr bekommt: welche Namespaces ohne Policy laufen, welche Regeln durch das eingesetzte CNI gar nicht durchgesetzt werden, welche Selektoren ins Leere greifen, und eine Reihenfolge für die Einführung von Default-Deny. Pexon ist ISO 27001 zertifiziert, im Team sind CKA, CKAD, CKS und KCNA. Servicezeit Mo-Fr 08:00-18:00 MEZ.
Was der Angriffsflächen-Check nicht ist
Ein Konfigurations-Review, kein Pentest. Wir greifen euren Cluster nicht an, wir exploiten nichts und wir stellen kein Prüftestat aus - Testate erteilen nur akkreditierte Stellen. Was wir liefern, ist ein Befundbericht über den Ist-Zustand eurer Konfiguration.
Wenn ihr einen echten Penetrationstest braucht, etwa weil ein Kunde ihn vertraglich verlangt, sagen wir das und vermitteln einen Partner, der ihn für 8.000 EUR durchführt. Das ist ein anderes Produkt mit einem anderen Ergebnis. Wer beides verwechselt, kauft für 850 EUR etwas, das den Nachweis nicht erbringt.
Verwandte Seiten im Security-Zweig
- Kubernetes Security - der Hub mit Self-Check, Angriffsflächen-Check und Compliance-Snapshot
- Kubernetes RBAC - wer im Cluster was darf, die Rechte-Seite zu dieser Netz-Seite
- Kubernetes Policies mit Kyverno und OPA Gatekeeper - Regeln, die schon beim Deployment greifen
- Image Scanning - Schwachstellen in Container-Images finden, bevor sie im Cluster laufen
- Container Security - der Blick auf die Laufzeit
- Kubernetes Security Hardening Checkliste - die bestehende Liste zum Durcharbeiten
Häufige Fragen zu Kubernetes Network Policies
Warum greift meine Network Policy nicht?
Meistens am CNI. Die NetworkPolicy-API ist Teil von Kubernetes, die Durchsetzung nicht: Flannel und einige Managed-Standardkonfigurationen ignorieren die Objekte stillschweigend, das Manifest wird trotzdem angenommen. Zweithäufigster Grund: der Pod-Selector trifft die Labels nicht. Prüft zuerst, welches CNI läuft, und testet danach aus einem Debug-Pod, ob die Verbindung wirklich fällt.
Brauche ich Cilium oder reicht die Kubernetes Network Policy API?
Die Standard-API reicht für L3 und L4: Pods, Namespaces, Ports. Sobald ihr auf HTTP-Methoden, Pfade oder DNS-Namen filtern wollt, braucht ihr eine CiliumNetworkPolicy oder eine vergleichbare CRD. Unser Rat: startet mit der Standard-API, weil sie portabel bleibt, und wechselt erst dann auf CRDs, wenn eine konkrete Regel sich anders nicht abbilden lässt.
Wie führe ich Default-Deny ein, ohne dass die Anwendung ausfällt?
In zwei Schritten. Erst beobachtet ihr den tatsächlichen Traffic pro Namespace, über Flow-Logs des CNI oder eine Policy im Audit-Modus. Dann schreibt ihr die Allow-Regeln für genau diese Verbindungen, rollt Default-Deny zuerst in einem unkritischen Namespace aus und wartet einen vollen Werktag ab, inklusive Nacht-Jobs und Cronjobs, bevor der nächste Namespace folgt.
Blockiert eine Network Policy auch DNS?
Ja, und das ist der häufigste Selbstschuss. Ein Default-Deny auf Egress blockiert auch die Anfragen an kube-dns oder CoreDNS im Namespace kube-system. Die Anwendung wirft dann Namensauflösungs-Fehler, nicht Verbindungsfehler, was die Suche verzögert. Nehmt die DNS-Regel deshalb in dieselbe Policy auf, mit der ihr Default-Deny einführt, nicht in eine spätere.
Gilt eine Network Policy für alle Namespaces?
Nein. Eine NetworkPolicy ist ein namespaced Objekt und wirkt nur auf Pods im eigenen Namespace. Cluster-weite Regeln brauchen eine CRD, etwa CiliumClusterwideNetworkPolicy oder die GlobalNetworkPolicy von Calico. Praktisch heißt das: jeder neue Namespace kommt ohne Schutz auf die Welt. Legt Default-Deny deshalb in die Namespace-Vorlage eures GitOps-Repos, nicht in eine Checkliste.
Verlangt NIS2 Netzwerksegmentierung im Cluster?
NIS2 nennt keine Kubernetes-Objekte. Die Richtlinie ist über das BSIG am 06.12.2025 in Kraft getreten und verlangt Risikomanagement für Netz- und Informationssysteme, nicht eine bestimmte YAML-Datei. In Audits taucht die Frage trotzdem auf, weil ein flaches Cluster-Netz die Frage nach Segmentierung auslöst. Eine dokumentierte Default-Deny-Linie pro Namespace ist die einfachste Antwort darauf.
So fangt ihr an: kostenloser Self-Check mit 20 Punkten
Der Self-Check kostet nichts und hat 20 Punkte. Drei davon betreffen das Cluster-Netz direkt: welches CNI läuft, wie viele Namespaces ohne Network Policy arbeiten, und ob Egress irgendwo begrenzt ist. Wenn ihr die drei nicht aus dem Kopf beantworten könnt, habt ihr den Befund schon.
Danach entscheidet ihr, ob es beim Self-Check bleibt oder ob wir uns die Manifeste ansehen. Der Angriffsflächen-Check ab 850 EUR dauert 0,5 bis 1 Personentag und endet mit einer Reihenfolge, nicht mit einer Liste. Erstgespräch buchen - ihr bringt euer CNI und die Zahl eurer Namespaces mit.