NetworkPolicy-Debugging: Die blockierende Rule finden

NetworkPolicy-Debugging: Die blockierende Rule finden – genau daran scheitern viele Kubernetes-Teams, weil NetworkPolicies auf den ersten Blick simpel wirken, in der Realität aber aus mehreren Ebenen bestehen: Label-Selektoren, Namespace-Selektoren, Ports/Protokolle, Richtungslogik (Ingress/Egress), Default-Deny-Effekte, CNI-spezifische Umsetzung (iptables, nftables, eBPF) und nicht zuletzt die Frage, ob das Cluster überhaupt NetworkPolicy erzwingt. Das typische Fehlerbild ist immer ähnlich: „Gestern ging es noch, heute ist ein Service nicht erreichbar“, „DNS klappt nur sporadisch“, „Pod A erreicht Pod B nicht mehr“ oder „Nur über den Service-Namen geht es nicht“. Um die blockierende Rule zuverlässig zu finden, brauchen Sie eine strukturierte Vorgehensweise: erst feststellen, ob NetworkPolicy überhaupt der Schuldige ist, dann den betroffenen Datenpfad sauber definieren, anschließend die Policy-Menge auf den Ziel-Pod eingrenzen und schließlich die konkrete Ursache isolieren – etwa ein fehlendes Label, eine zu enge Port-Definition, ein falsch gesetzter NamespaceSelector oder eine Egress-Policy, die DNS oder egress NAT unbeabsichtigt blockiert. Dieser Artikel zeigt eine praxistaugliche Schritt-für-Schritt-Methodik, mit der Sie die blockierende NetworkPolicy identifizieren und beheben, ohne stundenlang „rumzuprobieren“.

Grundlagen: Was NetworkPolicy tatsächlich macht (und was nicht)

Kubernetes NetworkPolicy ist ein L3/L4-Mechanismus: Sie steuert, welche Quellen/Ziele (Pods, Namespaces, CIDRs) über welche Ports und Protokolle kommunizieren dürfen. Entscheidend ist: NetworkPolicy ist kein Kubernetes-Core-Feature, das automatisch wirkt. Sie wird von der CNI-Implementierung (oder einem separaten Policy-Controller) umgesetzt. Wenn Ihr CNI NetworkPolicy nicht unterstützt oder Policy-Enforcement deaktiviert ist, sind Policies „nur YAML ohne Wirkung“.

• NetworkPolicy ist deklarativ: Sie beschreibt erlaubten Verkehr, nicht den gesamten Datenpfad.
• Enforcement ist CNI-abhängig: iptables/nftables/eBPF-Regeln werden außerhalb der API realisiert.
• Policies sind additive Allow-Listen: Es gibt kein „Deny“ in der Standard-NetworkPolicy-API, sondern erlaubte Flows; alles andere kann implizit blockiert sein.

Offizielle Referenzen: Kubernetes Network Policies sowie die Spezifikation der API-Objekte unter NetworkPolicy (policy/v1) API Reference.

Der wichtigste Debugging-Hebel: Verstehen, wann „Default Deny“ aktiv wird

Das häufigste Missverständnis: „Ich habe eine Policy erstellt, die nur einen kleinen Teil regelt.“ In der Praxis löst schon eine einzige Policy für einen Pod-Selektor den Wechsel von „alles erlaubt“ zu „nur explizit erlaubt“ aus – allerdings nur in der jeweils betroffenen Richtung. Sobald ein Pod von mindestens einer Ingress-Policy selektiert wird, ist sein Ingress-Verkehr auf das erlaubt, was durch mindestens eine passende Ingress-Regel abgedeckt ist. Gleiches gilt für Egress, wenn eine Egress-Policy den Pod selektiert.

• Ingress Default Deny: tritt für einen Pod ein, sobald eine Ingress-Policy diesen Pod selektiert.
• Egress Default Deny: tritt für einen Pod ein, sobald eine Egress-Policy diesen Pod selektiert.
• Additiv: Mehrere Policies erweitern den erlaubten Verkehr, sie „überschreiben“ sich nicht im Sinne von Prioritäten.

Wenn Sie die blockierende Rule finden wollen, müssen Sie daher zuerst klären: Ist es ein Ingress- oder Egress-Problem – oder beides?

Schritt 1: Den Datenpfad konkret machen (ohne Annahmen)

NetworkPolicy-Debugging scheitert oft, weil der „Fail“ zu vage beschrieben wird. Formulieren Sie den Pfad so konkret wie möglich:

• Quelle: Pod-Name, Namespace, Labels (z. B. app=frontend)
• Ziel: Pod-Name oder Service, Namespace, Labels (z. B. app=backend)
• Protokoll/Port: TCP/443, TCP/5432, UDP/53 etc.
• Art des Zugriffs: direkt auf Pod-IP oder über Service-DNS/ClusterIP
• Richtung: Aus Sicht des Quell-Pods ist es Egress; aus Sicht des Ziel-Pods ist es Ingress

Wichtig: Wenn ein Zugriff über Service-Namen scheitert, kann die Blockade auch DNS betreffen (UDP/TCP 53 zu CoreDNS) oder Service-Routing (kube-proxy/eBPF) – nicht nur die direkte App-Verbindung.

Schritt 2: Prüfen, ob NetworkPolicy überhaupt die Ursache ist

Bevor Sie Policies sezieren, stellen Sie sicher, dass der Fehler nicht auf einer anderen Ebene liegt. Das spart Zeit und verhindert Fehlfixes.

• Ist das Ziel gesund? Läuft der Pod? Lauscht der Prozess auf dem erwarteten Port? Sind Readiness/Liveness ok?
• Ist es DNS oder Netzwerk? Testen Sie Namensauflösung separat von Port-Erreichbarkeit.
• Ist das Routing grundsätzlich ok? Funktioniert Pod-IP zu Pod-IP im selben Namespace ohne Service dazwischen?
• Unterstützt das CNI NetworkPolicy? Dokumentation des CNI prüfen, ggf. Feature-Flags.

Gerade der letzte Punkt ist kritisch: Manche CNIs unterstützen NetworkPolicy nur eingeschränkt oder benötigen explizite Aktivierung. Cilium erklärt das Enforcement-Konzept und eBPF-Policy unter Cilium Network Policy, Calico die Policy-Umsetzung unter Calico Kubernetes NetworkPolicy.

Schritt 3: Betroffene Pods identifizieren (welche Policies selektieren wirklich?)

Die „blockierende Rule“ ist oft nicht die Policy, die Sie zuletzt geändert haben, sondern eine Policy, die plötzlich auf mehr Pods zutrifft – weil Labels geändert wurden, Deployments neue Labels bekommen haben oder Namespace-Labels angepasst wurden. Debugging beginnt daher mit der Frage: Welche Policies selektieren den Ziel-Pod (Ingress) und welche selektieren den Quell-Pod (Egress)?

Typische Ursachen für unerwartete Selektoren

• Label Drift: Ein Deployment wurde neu ausgerollt und hat Labels verloren oder geändert.
• NamespaceSelector wirkt anders als gedacht: Namespace-Labels fehlen oder sind inkonsistent.
• Leere PodSelector: podSelector: {} selektiert alle Pods im Namespace – oft unbeabsichtigt.
• MatchExpressions zu breit: In-Operatoren treffen auf mehr Pods als geplant.

Schritt 4: Ingress oder Egress isolieren – mit kontrollierten Tests

Um die blockierende Richtung zu finden, nutzen Sie Tests, die jeweils nur eine Komponente prüfen. Der Wert liegt nicht im konkreten Tool, sondern im Prinzip: erst IP, dann Port, dann Name/HTTP.

• Test A (DNS): Löst der Quell-Pod den Service-Namen auf?
• Test B (Layer 4): Erreicht der Quell-Pod den Zielport (z. B. TCP connect)?
• Test C (Pod-IP): Funktioniert der Zugriff auf die Pod-IP direkt (ohne Service)?
• Test D (Response): Kommt eine Antwort zurück oder hängt es (Timeout vs. sofortiger Reset)?

Wenn DNS nicht funktioniert, ist häufig eine Egress-Policy schuld, die UDP/TCP 53 Richtung kube-dns/CoreDNS nicht erlaubt. Wenn Pod-IP klappt, aber Service nicht, ist das Problem eher im Service-Layer (kube-proxy/eBPF) oder in einer Policy, die nur den Service-Pfad indirekt betrifft.

Schritt 5: Die Policy-Logik korrekt „lesen“ (Additivität statt Priorität)

Standard-Kubernetes-NetworkPolicies kennen keine Prioritäten. Es gibt nicht „die eine“ Regel, die gewinnt. Stattdessen gilt: Für einen Pod ist ein Flow erlaubt, wenn mindestens eine passende Policy in der jeweiligen Richtung den Flow erlaubt. Das ist die zentrale Denkweise, um die blockierende Rule zu finden: Sie suchen nicht nach „Deny“, sondern nach dem fehlenden „Allow“.

Praktische Konsequenz

• Wenn etwas blockiert ist, fehlt in der Menge der relevanten Policies eine Regel, die genau diesen Flow abdeckt.
• Die „blockierende Rule“ ist häufig eine unbeabsichtigte Default-Deny-Wirkung durch das Vorhandensein einer Policy.
• Fix ist meist: eine gezielte Allow-Regel ergänzen (oder Selektor enger machen), nicht „eine Deny-Regel entfernen“.

Die häufigsten Blocker-Muster und wie Sie sie schnell erkennen

DNS wird blockiert (der Klassiker bei Egress Default Deny)

Symptome: Service-Namen lösen nicht auf, externe Namen ebenfalls nicht, Workloads melden „no such host“, „i/o timeout“, „temporary failure in name resolution“. Ursache: Eine Egress-Policy selektiert den Pod, erlaubt aber keinen Verkehr zu CoreDNS (kube-system) auf UDP/TCP 53.

• Prüfen: Gibt es eine Egress-Policy für den Quell-Pod?
• Prüfen: Erlaubt sie Traffic zu kube-dns/CoreDNS (Namespace/PodSelector) auf 53?
• Prüfen: Ist CoreDNS in einem anderen Namespace oder mit anderen Labels als angenommen?

Hintergrund zu DNS in Kubernetes: DNS for Services and Pods.

NamespaceSelector passt nicht (fehlende Namespace-Labels)

Symptome: Eine Policy „sollte“ Zugriff aus einem Namespace erlauben, aber in der Praxis wird geblockt. Ursache: namespaceSelector matcht nur Namespaces mit bestimmten Labels; wenn diese Labels fehlen, ist der Namespace nicht eingeschlossen.

• Prüfen: Welche Labels hat der Quell-Namespace wirklich?
• Prüfen: Ist die Policy auf Labels angewiesen, die in manchen Umgebungen nicht gesetzt werden?
• Fix: Namespace-Labeling standardisieren oder Policy auf robustere Selektoren umstellen.

Ports sind zu eng definiert (TCP 443 erlaubt, aber Healthcheck auf 10254 blockiert)

Symptome: App funktioniert teilweise, aber Healthchecks, Metrics oder Sidecar-Kommunikation schlägt fehl. Ursache: Die Policy erlaubt nur den „Hauptport“, aber nicht Nebenports (Prometheus Scrape, Envoy Admin, gRPC Health, Webhooks).

• Prüfen: Welche Ports nutzt die Anwendung wirklich (inkl. Sidecars)?
• Prüfen: Werden Protokolle korrekt angegeben (TCP vs. UDP)?
• Fix: Ports bewusst ergänzen oder Nebenfunktionen auf definierte Routen/Namespaces legen.

Egress zu externen Zielen ist blockiert (CIDR fehlt oder ist falsch)

Symptome: Interne Calls funktionieren, externe APIs nicht, Container können keine Pakete ziehen, Timeouts bei Outbound HTTPS. Ursache: Egress-Policy erlaubt nur clusterinterne Ziele oder nur bestimmte CIDRs.

• Prüfen: Wird Internet-Egress überhaupt erlaubt?
• Prüfen: Gibt es NAT/Egress-Gateway, das eine andere Ziel-IP erscheinen lässt?
• Fix: CIDR-Ausnahmen gezielt ergänzen, oder Egress über Proxy/Gateway erzwingen und nur diesen erlauben.

Service-Mesh/mTLS verändert Datenpfade

Symptome: Vor Einführung eines Sidecars funktionierte der Traffic, danach nicht. Ursache: Sidecars bauen eigene Verbindungen zu Control Planes, Telemetry, Zertifikatsdiensten auf; außerdem ändern sich Ports und Ziel-IPs aus Sicht der Policies.

• Prüfen: Welche zusätzlichen Ziele/Ports benötigt das Mesh?
• Prüfen: Greifen Policies auf PodLabels, die durch Sidecar-Injection geändert wurden?
• Fix: Mesh-spezifische Allow-Policies (Control Plane, Telemetry, DNS) konsistent einführen.

Systematisches Vorgehen: Die blockierende Rule in 8 klaren Schritten

• 1) Problem präzisieren: Quelle, Ziel, Port, Protokoll, über Service oder Pod-IP.
• 2) Richtung bestimmen: Scheitert Egress aus Quelle oder Ingress am Ziel (oder beides)?
• 3) Prüfen, ob Policies enforced werden: CNI-Features, ggf. CNI-Doku, Test mit bewusst restriktiver Policy in Test-Namespace.
• 4) Relevante Policies sammeln: Alle Policies, die den Quell-Pod (Egress) oder Ziel-Pod (Ingress) selektieren.
• 5) Default Deny feststellen: Gibt es überhaupt eine Policy in der Richtung? Wenn ja, ist „nur erlaubt, was erlaubt ist“ aktiv.
• 6) Selektoren verifizieren: PodLabels und NamespaceLabels im Ist-Zustand prüfen (nicht aus Helm-Werten raten).
• 7) Ports/Protokolle abgleichen: Realität der Verbindung (TCP/UDP, Port, Nebenports, DNS) gegen Policy.
• 8) Minimalen Fix bauen: Fehlenden Allow ergänzen oder Selektor korrigieren, dann Wirkung über Tests und Logs verifizieren.

Debugging-Tools und Signale: Was Ihnen wirklich hilft

Ohne Observability bleibt NetworkPolicy-Debugging mühsam. Welche Tools sinnvoll sind, hängt vom CNI ab. Der gemeinsame Nenner: Sie brauchen entweder Policy-Entscheidungslogs („dropped because…“) oder zumindest Paket-/Flow-Signale (Drops, Conntrack, iptables counters).

Wenn Ihr CNI iptables/nftables nutzt

• iptables counters: Zähler an Chains können zeigen, welche Regeln „treffen“.
• Conntrack: Sicht auf aktive Verbindungen und Timeouts.
• tcpdump: verifizieren, ob Pakete am Node ankommen/gehen (hilft besonders bei Timeout vs. Reset).

Wenn Ihr CNI eBPF nutzt

eBPF-basierte CNIs können oft bessere Einsicht liefern, weil Policy-Entscheidungen näher am Datenpfad beobachtbar sind. Bei Cilium sind z. B. Hubble und Policy-Visibility ein verbreiteter Ansatz für „wer redet mit wem und was wird gedroppt“. Einstieg: Cilium Hubble Observability.

Wichtige Debugging-Signale unabhängig vom Tool

• Timeout deutet oft auf Drop/Block hin (Policy, Routing, MTU), während ein sofortiger Reset eher für „Service nicht lauscht“ oder aktive Rejects spricht.
• DNS-Timeouts sind häufig Egress-Policy-Probleme oder CoreDNS-Überlastung.
• Nur Service-IP kaputt deutet auf Service-Layer (kube-proxy/eBPF) oder Endpoints hin, nicht zwingend auf reine Pod-to-Pod-Connectivity.

Mehrere Policies gleichzeitig: So vermeiden Sie falsche Schlüsse

In größeren Clustern existieren meist mehrere Policy-Schichten: Baseline-Policies (z. B. Default Deny im Namespace), team-spezifische Policies und manchmal zusätzliche CNI-spezifische Erweiterungen (z. B. Calico GlobalNetworkPolicy oder CiliumClusterwideNetworkPolicy). Das kann Debugging verkomplizieren, weil der „Block“ nicht aus einer einzigen NetworkPolicy stammen muss.

• Baseline-Policies: häufig Default Deny plus erlaubte Standarddienste (DNS, NTP, Metrics).
• App-Policies: erlauben gezielt Ingress/Egress zwischen Services.
• Erweiterte Policies: CNI-spezifische CRDs mit globaler Wirkung (je nach CNI).

Wenn Sie in so einer Umgebung arbeiten, prüfen Sie explizit, ob neben Standard-NetworkPolicies zusätzliche Policy-CRDs aktiv sind. Calico und Cilium dokumentieren ihre erweiterten Policy-Modelle jeweils in ihren offiziellen Guides, z. B. Calico GlobalNetworkPolicy oder Cilium Policy Language.

Die häufigsten „blockierenden Regeln“ sind eigentlich Datenqualitätsprobleme

In der Praxis liegt die Ursache sehr oft nicht in „falscher Logik“, sondern in Datenqualität: Labels, die nicht gesetzt sind, Namespaces, die uneinheitlich klassifiziert sind, oder Workloads, die Ports dynamisch nutzen. Deshalb lohnt es sich, Debugging-Erkenntnisse in Standards zu überführen.

• Namespace-Label-Standard: z. B. team=, environment=, exposure= – und Policies, die darauf aufbauen.
• Service-Labels stabil halten: app= und role= konsistent, damit PodSelectors nicht „driften“.
• Standard-Egress-Ausnahmen: DNS, Zeitserver, interne Artifact-Repos/Registries, Monitoring.
• Dokumentierte Port-Landkarte: Hauptports plus Nebenports (Metrics, Health, Webhooks, Sidecar-Control).

Minimal-invasive Fixes: Wie Sie schnell wieder Betrieb herstellen, ohne Sicherheit zu verlieren

Wenn Produktion brennt, ist die Versuchung groß, eine Policy „kurz zu öffnen“. Change Safety bedeutet, dass Sie temporäre Ausnahmen so klein wie möglich halten, klar dokumentieren und wieder entfernen. Der beste Fix ist meist eine präzise Allow-Regel statt einer breiten CIDR-Öffnung.

• Bevorzugt: PodSelector/NamespaceSelector statt 0.0.0.0/0.
• Bevorzugt: nur benötigte Ports/Protokolle (TCP 443 statt „alle Ports“).
• Temporär: Ausnahme mit Ablaufdatum und Owner.
• Nacharbeit: Root Cause (Labels, Standard-Policies, Service Mesh Anforderungen) sauber beheben.

Checkliste: Schnell die blockierende Rule finden

• Ist NetworkPolicy-Enforcement im CNI aktiv und unterstützt?
• Welche Pods sind Quelle und Ziel – welche Labels/Namespace-Labels haben sie wirklich?
• Ist es Ingress, Egress oder DNS?
• Selektiert mindestens eine Policy den Pod in der betroffenen Richtung (Default Deny aktiv)?
• Gibt es mindestens eine Allow-Regel, die genau diesen Flow abdeckt?
• Stimmen Port und Protokoll (TCP/UDP), inklusive Nebenports?
• Wird über Service oder direkt über Pod-IP getestet (Unterschiede notieren)?
• Gibt es zusätzliche CNI-spezifische Policy-Objekte mit globaler Wirkung?

Weiterführende Quellen für NetworkPolicy-Debugging und Implementierungen

• Kubernetes Network Policies: Konzepte und Verhalten
• NetworkPolicy API Reference (policy/v1)
• DNS for Services and Pods: CoreDNS und typische Fehlerbilder
• Calico: Umsetzung von Kubernetes NetworkPolicy
• Calico GlobalNetworkPolicy: globale Policies und Debugging-Kontext
• Cilium: Policy-Enforcement und Konzepte
• Cilium Hubble: Observability für erlaubte und gedroppte Flows

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:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

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.