Site icon bintorosoft.com

NetworkPolicy greift nicht? Debug Step-by-Step (Calico/Cilium etc.)

Red Snapper

Wenn eine NetworkPolicy greift nicht-Situation in Kubernetes auftritt, ist das fast immer frustrierend: Sie haben eine Policy definiert, erwarten „Default Deny“ oder gezielte Freigaben – und trotzdem fließt Traffic scheinbar unbegrenzt weiter. In der Praxis liegt das selten daran, dass Kubernetes „NetworkPolicies ignoriert“, sondern daran, dass eine von mehreren Voraussetzungen nicht erfüllt ist: Das CNI-Plugin unterstützt die Kubernetes-API nicht (oder nur teilweise), die Policy matcht nicht die richtigen Pods (Labels/NamespaceSelector), es existiert bereits eine allowende Policy, die Sie übersehen haben, oder es gibt Traffic-Pfade, die an der Policy-Ebene vorbeigehen (HostNetwork, NodePort, Ingress Controller, Service Mesh, eBPF/iptables-Interaktionen). Dieses Runbook führt Sie Schritt für Schritt durch ein Debugging, das in Calico, Cilium und ähnlichen CNIs funktioniert. Ziel ist, reproduzierbar zu prüfen: Wird die Policy überhaupt „programmiert“? Trifft sie den gewünschten Traffic? Und wenn nicht – welche konkrete technische Ursache steckt dahinter? Sie bekommen eine klare Reihenfolge, typische Fehlerbilder und sichere Remediation-Optionen, ohne reflexartig „allow all“ einzuschalten.

Grundverständnis: Was eine NetworkPolicy leisten kann – und was nicht

Kubernetes NetworkPolicies definieren Regeln für Pod-zu-Pod-Traffic (Ingress/Egress) anhand von Labels, Namespaces und Ports. Wichtig: Kubernetes selbst erzwingt diese Regeln nicht. Die Durchsetzung übernimmt das CNI (Container Network Interface) bzw. dessen Datenpfad (iptables, IPVS, eBPF oder Kombinationen). Wenn das CNI keine NetworkPolicies unterstützt oder die Policy-Funktion deaktiviert ist, bleibt eine NetworkPolicy „Papier“. Außerdem gelten Policies in der Regel nur für Pods, nicht für Node-Prozesse oder reine Host-Netzwerkpfade.

Symptom präzisieren: „Greift nicht“ heißt nicht immer „wird ignoriert“

Bevor Sie tiefer debuggen, definieren Sie das Symptom konkret. Viele Fälle, die wie „NetworkPolicy greift nicht“ aussehen, sind tatsächlich ein Mismatch zwischen Erwartung und tatsächlichem Datenpfad.

Schritt 1: Prüfen, ob NetworkPolicies im Cluster überhaupt durchgesetzt werden

Der häufigste Grund: Das eingesetzte CNI unterstützt NetworkPolicy nicht oder nicht in der erwarteten Form. Auch bei unterstützenden CNIs kann die Funktion deaktiviert sein.

Schnelltest: Minimaler Default Deny im Test-Namespace

Erstellen Sie in einem dedizierten Test-Namespace eine Default-Deny-Policy und prüfen Sie, ob Pod-zu-Pod- bzw. Pod-zu-DNS-Traffic wie erwartet blockiert wird. Wenn hier keine Wirkung entsteht, ist das Problem meist CNI/Enforcement, nicht Ihre konkrete Policy-Logik.

Schritt 2: Ist die Policy syntaktisch korrekt und im richtigen Namespace?

NetworkPolicies sind namespaced. Eine Policy im falschen Namespace greift nicht – selbst wenn Labels gleich heißen. Auch kleine YAML-Fehler führen zu „Policy existiert, aber matcht nichts“.

Typischer Fehler: Labels stimmen nicht (oder ändern sich)

Wenn Deployments Labels nachträglich ändern (oder Helm-Templates andere Labels setzen), kann eine Policy „plötzlich“ nicht mehr matchen. Stabilisieren Sie Labels, die für Policies verwendet werden (z. B. app, component, tier) und vermeiden Sie volatile Labels wie Build-Hashes.

Schritt 3: Der wichtigste Punkt – welche Pods sind tatsächlich selektiert?

Die meisten „greift nicht“-Fälle sind Selektor-Probleme. Behandeln Sie das wie eine Menge: Die Policy wirkt nur auf die Schnittmenge aus Namespace und podSelector.

Mentales Modell als einfache Menge

WirksamePods = PodsImNamespace ∩ PodsMitLabels

Schritt 4: Gibt es eine andere Policy, die Ihren Traffic erlaubt?

Ein verbreitetes Missverständnis: NetworkPolicies sind additiv. Sobald ein Pod von irgendeiner Ingress-Policy selektiert ist, ist Ingress für diesen Pod grundsätzlich „restricted“, aber alle erlaubenden Regeln aus allen passenden Policies addieren sich. Das bedeutet: Eine einzige zu breite Allow-Policy kann Ihre restriktive Policy „aushebeln“.

Anti-Pattern: „Temporäre“ Allow-Policies, die dauerhaft bleiben

In Incidents werden manchmal breite Freigaben gesetzt („nur kurz“). Wenn diese später nicht entfernt werden, erscheinen neue Policies wirkungslos. Etablieren Sie eine Praxis: Jede temporäre Policy bekommt ein Ablaufdatum (Prozess/Change), Ownership und Ticket-Referenz.

Schritt 5: Prüfen, ob der Traffic-Pfad an NetworkPolicy vorbeigeht

NetworkPolicies wirken auf den Pod-Datenpfad. Einige Kubernetes-Features und Betriebsweisen können Traffic erzeugen, der nicht so gefiltert wird, wie man es intuitiv erwartet.

Praktische Einordnung: Wer ist der echte Source Pod?

Wenn Sie „Ingress sperren“ wollen, müssen Sie wissen, welcher Pod tatsächlich die Verbindung aufbaut. Bei Ingress ist das der Ingress Controller, bei Jobs/Sidecars ist es eventuell ein anderer Container. Prüfen Sie Quell-IPs/Labels anhand von Logs (CNI/Flow Logs) statt nur anhand des gewünschten Architekturbilds.

Schritt 6: Calico-spezifische Checks (Kubernetes NetworkPolicy vs. Calico Policy)

Calico unterstützt Kubernetes NetworkPolicies sehr gut, bringt aber zusätzlich eigene CRDs (GlobalNetworkPolicy, NetworkPolicy im Calico-Sinne) und Profile/Defaults mit. Dadurch können Effekte entstehen, die Sie ohne Calico-Kontext übersehen.

Typischer Calico-Fall: NamespaceSelector matcht nicht, weil Namespace nicht gelabelt ist

Calico-Nutzer arbeiten gern mit namespaceSelector. Wenn Namespaces aber keine Labels tragen, matcht der Selector niemanden. Stellen Sie sicher, dass Namespaces die erwarteten Labels besitzen oder verwenden Sie podSelector innerhalb des Namespace.

Schritt 7: Cilium-spezifische Checks (Kubernetes NetworkPolicy vs. CiliumNetworkPolicy)

Cilium kann Kubernetes NetworkPolicies durchsetzen, bietet aber zusätzlich erweiterte Features über CiliumNetworkPolicy (L7-Regeln, FQDN-Policies, DNS-aware Egress) und arbeitet häufig eBPF-basiert. Das kann Debugging verändern: Sie prüfen dann nicht nur „iptables-Regeln“, sondern eBPF-Policy-Maps, Observability (Hubble) und ggf. L7-Proxies.

Typischer Cilium-Fall: Policy ist korrekt, aber Sidecar/Port-Mapping ist anders

In Mesh-Setups oder bei transparenten Proxies kann die tatsächliche Verbindung über andere Ports laufen als erwartet (z. B. 15001/15006 bei Sidecars). Eine Policy, die nur „App-Port 8080“ erlaubt, kann dann scheinbar nicht greifen, weil der Traffic einen anderen Port nutzt.

Schritt 8: Tests richtig durchführen – sonst debuggen Sie die falsche Realität

Ein häufiger Grund für Fehldiagnosen ist ein falscher Test. Beispiel: Sie testen Egress aus einem Debug-Pod, der keine Labels hat und daher nicht unter die Policy fällt. Oder Sie testen „Ingress“ über einen Service, obwohl die Policy nur Pod-IP-basierte Flows betrifft.

Schritt 9: Visibility – so finden Sie die Policy, die tatsächlich entscheidet

Ohne Sichtbarkeit wirkt NetworkPolicy-Debugging wie Rätselraten. Nutzen Sie Logs und Flow-Telemetrie, um zu sehen, ob Flows geblockt werden und durch welche Regel.

Minimaler Nachweis: Policy greift vs. greift nicht

Schritt 10: Häufige Root Causes (mit schnellen Fix-Hinweisen)

Remediation: Sichere Vorgehensweise, um Policies „korrekt greifend“ zu machen

Wenn Sie die Ursache identifiziert haben, setzen Sie Fixes kontrolliert um. Priorisieren Sie dabei Stabilität und Nachvollziehbarkeit.

Change-Disziplin: Eine Variable nach der anderen

Ändern Sie beim Debugging nicht gleichzeitig Labels, Policy und CNI-Konfiguration. Sonst wissen Sie nicht, welche Änderung den Effekt verursacht hat. Führen Sie Änderungen sequenziell durch und validieren Sie jeweils mit demselben Testset.

Copy-Paste-Runbook: NetworkPolicy greift nicht – Debug Step-by-Step

Outbound-Links zu relevanten Informationsquellen

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

Lieferumfang:

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.

 

Exit mobile version