Network Policies in Kubernetes: Vom CNI bis zur OSI-Schicht

Network Policies in Kubernetes sind der Schlüssel, um Ost-West-Traffic (Pod-zu-Pod) und Egress-Verbindungen (Pod-nach-außen) kontrolliert, nachvollziehbar und sicher zu betreiben. Viele Teams starten mit Kubernetes, weil Deployments und Skalierung schnell gehen – und stellen später fest, dass „ein Cluster“ ohne saubere Netzgrenzen zu einem flachen Netzwerk wird: Jeder Pod kann theoretisch jeden anderen erreichen, Services werden „einfach erreichbar“, und die Fehlersuche bei Security- oder Connectivity-Themen wird zum Ratespiel. Genau hier setzen Network Policies an: Sie definieren, welche Workloads miteinander kommunizieren dürfen, auf welchen Ports und Protokollen – und in welchem Umfang. Damit das im Betrieb zuverlässig funktioniert, muss man jedoch verstehen, wie Policies mit dem CNI-Plugin, der Datenebene (Data Plane) und den OSI-Schichten zusammenspielen. Dieser Artikel erklärt das Zusammenspiel von CNI bis zur OSI-Schicht, zeigt typische Fallstricke und liefert praxisnahe Best Practices, damit Network Policies in Kubernetes nicht nur „konfiguriert“, sondern wirklich wirksam sind.

Warum Network Policies in Kubernetes oft missverstanden werden

Ein verbreitetes Missverständnis: Kubernetes „hat“ Network Policies, also sei die Segmentierung bereits vorhanden. Tatsächlich definiert Kubernetes nur die API (also das Objekt NetworkPolicy) und die Semantik. Die Durchsetzung übernimmt das CNI-Plugin (oder eine ergänzende Policy-Engine) – und nicht jedes CNI unterstützt NetworkPolicy gleichermaßen. Ohne kompatibles CNI bleibt die Policy entweder wirkungslos oder wirkt nur teilweise. Ebenso wichtig: NetworkPolicy ist in vielen Setups primär ein L3/L4-Konstrukt (IP/Port/Protokoll), während Teams manchmal L7-Filterung (HTTP-Methoden, Pfade, JWT-Claims) erwarten. Diese Erwartungslücke führt zu Sicherheitslücken („Wir dachten, das ist geblockt“) und zu Betriebsproblemen („Warum kommt trotzdem Traffic durch?“).

CNI-Grundlagen: Was das Plugin wirklich macht

CNI steht für Container Network Interface. Vereinfacht: Das CNI-Plugin verbindet Pods mit dem Netzwerk, weist ihnen IPs zu, installiert Routen/Interfaces und setzt – je nach Plugin – Regeln zur Traffic-Steuerung durch. In Kubernetes ist CNI die entscheidende Schicht zwischen Control Plane (deklarative Ressourcen) und Data Plane (Pakete, Routing, Firewall-Regeln).

Wichtige CNI-Aufgaben im Kontext von Network Policies:

• Pod-Connectivity herstellen: Virtuelle Interfaces (veth), Bridge/Overlay, Routing, Encapsulation (z. B. VXLAN, Geneve) oder reines Routing ohne Tunnel.
• Policy-Durchsetzung: Umsetzung von NetworkPolicy in iptables/nftables-Regeln, eBPF-Programmen oder proprietären Datenebenen.
• Identität/Labels abbilden: Übersetzung von Label-Selektoren in konkrete Endpunkte (Pods/IPs) und laufende Aktualisierung bei Scaling.
• Service-Traffic berücksichtigen: Zusammenspiel mit kube-proxy (iptables/ipvs) oder eBPF-Service-Implementierungen.

Wer tiefer einsteigen möchte: Die Spezifikation und Hintergründe zu CNI sind bei der CNI-Projektseite gut erklärt, während die Kubernetes-Perspektive auf NetworkPolicy in der Kubernetes-Dokumentation zu Network Policies beschrieben ist.

OSI-Mapping: Wo Network Policies im Stack tatsächlich wirken

Das OSI-Modell hilft, Erwartungen sauber zu kalibrieren. „Network Policies in Kubernetes“ sind kein monolithisches Feature, sondern hängen davon ab, wo im Stack Ihr CNI die Kontrolle implementiert.

• Layer 2 (Sicherung): Wird meist indirekt berührt (Bridges, VXLAN-Tunnel, MAC-Learning in Underlay/Overlay). Kubernetes-NetworkPolicy zielt nicht auf MAC-Ebene ab, kann aber durch die Implementierung (Bridge/Overlay) L2-Phänomene beeinflussen.
• Layer 3 (Vermittlung): Kernbereich: Pod-IP-Routing, CIDRs, Subnetze, Routen zwischen Nodes und ggf. zu externen Netzen.
• Layer 4 (Transport): Ebenfalls Kernbereich: TCP/UDP-Ports, Protokolle, Verbindungszustände (stateful/stateless je nach Engine).
• Layer 5–7: Mit Standard-NetworkPolicy typischerweise nicht abgedeckt. L7-Policies erfordern Erweiterungen (z. B. Service Mesh, spezielle CNI-Features oder zusätzliche Policy-Engines).

Wie Kubernetes NetworkPolicy semantisch funktioniert

Eine NetworkPolicy ist namespaced und selektiert Pods über Labels. Entscheidend sind drei Elemente: PodSelector (auf wen wirkt die Policy?), Ingress/Egress-Regeln (welche Flows sind erlaubt?) und policyTypes (Ingress, Egress oder beides).

Wichtige Prinzipien für den Betrieb:

• Default Allow ohne Policies: Wenn keine Policy einen Pod selektiert, ist Traffic in der Regel nicht eingeschränkt (CNI-spezifische Details beachten).
• Default Deny entsteht pro Richtung: Sobald eine Policy einen Pod für Ingress selektiert, ist Ingress nur noch erlaubt, wenn er explizit erlaubt wird. Gleiches gilt separat für Egress.
• Policies sind additive Allow-Listen: Mehrere Policies können sich ergänzen. „Deny-Regeln“ sind im Standardmodell nicht direkt vorhanden (einige CNIs bieten Erweiterungen).
• Selektoren sind dynamisch: Scaling, neue Pods und Label-Änderungen wirken sich sofort auf die Menge der erlaubten Endpunkte aus.

Vom YAML zur Paketrealität: Übersetzung in die Data Plane

Ob Ihre Policy in iptables, nftables oder eBPF landet, bestimmt die „Physik“ im Betrieb: Performance, Debugbarkeit, und auch Failure Modes. iptables-basierte Durchsetzung ist weit verbreitet und gut bekannt, kann aber bei großen Regelmengen komplex werden. eBPF-basierte Ansätze können sehr performant und observability-freundlich sein, erfordern jedoch andere Tooling- und Debugging-Skills.

Ein typisches Missverständnis: Service-IP vs. Pod-IP

NetworkPolicy matcht im Regelfall Pods (Endpoints), nicht Service-IPs. Das heißt: Wenn eine Anwendung „auf einen Service“ spricht, wird im Datenpfad irgendwann zu Pod-IPs aufgelöst – und genau dort greift die Policy. Je nach kube-proxy-Modus und CNI kann das Timing der NAT/Load-Balancing-Entscheidung variieren. Praktisch bedeutet das: Debugging sollte immer den tatsächlichen Ziel-Pod (Endpoint) betrachten, nicht nur den Service-Namen.

CNI-Realitäten: Unterschiede zwischen populären Implementierungen

In der Praxis entscheiden CNI-Details darüber, wie gut sich Network Policies betreiben lassen. Einige typische Unterscheidungsmerkmale:

• Policy-Abdeckung: Unterstützt das CNI Ingress und Egress vollständig? Gibt es Einschränkungen bei IPBlock, Named Ports oder bestimmten Protokollen?
• Durchsetzungsmechanik: iptables/nftables vs. eBPF, zentral vs. verteilt pro Node, stateful vs. stateless.
• Overlay vs. Routing: Tunnel (VXLAN/Geneve) können Underlay-Komplexität reduzieren, bringen aber MTU- und Encapsulation-Overhead. Reines Routing erfordert saubere Underlay-Routen.
• Observability: Welche Telemetrie ist nativ verfügbar (Flow-Logs, Drops, Policy-Hits)?

Für einen Einstieg in eBPF-basierte Netzfunktionen im Kubernetes-Kontext sind die Ressourcen von Cilium hilfreich; klassische NetworkPolicy-Umsetzungen und Erweiterungen sind z. B. bei Project Calico gut dokumentiert. Wichtig ist weniger „welches Produkt“, sondern dass die Features zu Ihrem Betriebsmodell passen.

Layer 3 in Kubernetes: CIDRs, Routing und IP-Adressierung verstehen

Auf Layer 3 entscheiden PodCIDR/ClusterCIDR, Node-Routen und ggf. externe Routen darüber, ob Traffic überhaupt ankommt – unabhängig von Policies. Viele „Policy-Probleme“ sind in Wahrheit Routing-Probleme: fehlende Rückroute, falsche MTU oder asymmetrisches Routing über NAT.

Ein häufiger Praxispunkt ist CIDR-Planung: Wie viele IPs bietet ein Subnetz wirklich? Das kann man mit einer einfachen Formel ableiten:

$\mathrm{IPs}=2^{32–\mathrm{Prefix}}$

Für IPv6 gilt entsprechend mit 128 Bit. In der Praxis sollten Sie zusätzlich Reserven für Systempods, DaemonSets und Spitzenlast einplanen. Wenn IPs knapp werden, kann das zu schwer erklärbaren Ausfällen führen, die dann fälschlich als Policy-Drops interpretiert werden.

Layer 4: Ports, Protokolle und stateful Verhalten

Network Policies arbeiten typischerweise mit TCP/UDP und optional SCTP (je nach Umgebung). Operativ relevant ist, ob die Durchsetzung stateful ist: Bei stateful Firewalls sind Rückpakete einer erlaubten Verbindung meist automatisch erlaubt. Bei stateless Regeln muss Rücktraffic explizit passen, sonst kommt es zu „halb offenen“ Verbindungen, Retransmissions und Timeouts.

• Ingress-Policy: Erlaubt eingehenden Traffic zu den Zielpods (Serverrolle).
• Egress-Policy: Erlaubt ausgehenden Traffic von Quellpods (Clientrolle) – oft unterschätzt, aber essenziell für „Default Deny“.
• Named Ports: Praktisch für Lesbarkeit, aber abhängig von korrekter Container-Portdefinition und CNI-Support.

DNS ist der häufigste Egress-Fallstrick

Viele Teams führen Egress-Default-Deny ein und wundern sich dann, dass „alles kaputt“ ist. Der häufigste Grund: DNS wird blockiert. Anwendungen nutzen DNS nicht nur beim Start, sondern laufend (Service Discovery, externe APIs, Short TTLs). Ein robustes Policy-Design berücksichtigt DNS explizit, inklusive UDP/TCP 53 und dem tatsächlichen Ziel (CoreDNS im Cluster oder ein externer Resolver).

• CoreDNS im Cluster: Egress zu den CoreDNS-Pods (Namespace/Labels beachten).
• NodeLocal DNSCache: Egress zu einer Node-lokalen IP/DaemonSet-Instanz – das ändert die Ziel-IP-Logik.
• Externer Resolver: Egress zu fest definierten Resolver-IPs, ggf. über NAT/Firewall-Grenzen.

Was NetworkPolicy nicht leistet: L7-Filterung und „Deny by Content“

Standard-NetworkPolicy kann nicht „nur GET auf /health erlauben“ oder „JWT-Claim X erzwingen“. Das ist Layer 7 und erfordert zusätzliche Mechanismen. Typische Ergänzungen:

• Service Mesh: mTLS, Identitäten, L7-Routing/Policies auf HTTP/gRPC-Ebene. Siehe z. B. Istio-Dokumentation.
• API-Gateway/Ingress: AuthN/AuthZ, Rate Limits, WAF-Regeln auf der Edge.
• CNI-Erweiterungen: Manche CNIs bieten L7-Policy-Funktionen oder Integrationen, die über Kubernetes-Standardobjekte hinausgehen.

Wichtig ist die saubere Trennung der Kontrollziele: NetworkPolicy für Netzwerkpfade (L3/L4), Mesh/Gateway für Anwendungsregeln (L7). So vermeiden Sie falsche Erwartungen und erhalten klarere Evidence im Betrieb.

Policy-Designmuster: Von „offen“ zu Zero-Trust im Cluster

Ein praktikabler Weg ist ein stufenweiser Ausbau:

• Stufe 1: Kritische Namespaces absichern (Default Deny Ingress) und nur notwendige Ingress-Pfade erlauben.
• Stufe 2: Egress kontrollieren (Default Deny Egress), DNS explizit erlauben, externe Abhängigkeiten whitelisten.
• Stufe 3: Microsegmentation zwischen Services (PodSelectors pro App/Team), nur definierte Service-to-Service-Pfade erlauben.
• Stufe 4: Identitätsbasierte Kontrollen (mTLS, Workload Identity) ergänzen, um IP-Dynamik elegant zu handhaben.

Für viele Organisationen ist das bereits ein erheblicher Sicherheitsgewinn, ohne dass der Betrieb unbeherrschbar wird.

Operative Realität: Troubleshooting von Policy-bedingten Ausfällen

Wenn eine Anwendung „nicht mehr funktioniert“, sind Policy-Drops nur eine mögliche Ursache. Ein OSI-orientiertes Vorgehen verkürzt die MTTR:

• L3 prüfen: Pod-IP erreichbar? Routen vorhanden? MTU/Fragmentierung? Asymmetrisches Routing?
• L4 prüfen: SYN/SYN-ACK/ACK sichtbar? Retransmissions? RSTs? Timeouts?
• Policy prüfen: Selektiert die Policy die richtigen Pods? Stimmen Labels/Namespaces? Gibt es eine unbeabsichtigte Default-Deny-Wirkung?
• DNS prüfen: Resolver erreichbar? Wird TCP 53 benötigt? Sind Search Domains korrekt?

Hilfreiche Tools sind u. a. Flow-Logs/Drops aus dem CNI, sowie Paketmitschnitte an strategischen Punkten (Pod, Node, Gateway). Wenn Ihr CNI Policy-Hits oder Drop-Reasons ausgeben kann, sollten diese Signale in Ihre Observability (Dashboards/Alerts) integriert werden.

Observability für Network Policies: Welche Signale wirklich zählen

Ohne Telemetrie werden Network Policies schnell zu „Black Box“-Regeln. Die wichtigsten Signale im Betrieb sind:

• Denied Flows (Drops): Quelle, Ziel, Port/Protokoll, Grund (Policy, conntrack, rp_filter, MTU).
• Policy-Hits: Welche Regeln werden tatsächlich genutzt? Welche sind tote Konfiguration?
• DNS-Metriken: NXDOMAIN-Rate, Latenz, Timeout-Rate, Query-Volumen.
• Service-Health: L4-Fehler (Retransmissions), L7-Fehler (5xx, Timeouts) zur Korrelation.

Wenn Sie Observability standardisieren möchten, orientieren Sie sich an „Golden Signals“ (Latency, Traffic, Errors, Saturation) und ergänzen Sie Policy-spezifische Drop-/Hit-Metriken. So werden Netzwerk- und App-Sicht zusammengeführt, statt getrennt zu debuggen.

Best Practices: Network Policies robust und auditierbar machen

• Label-Hygiene: Stabil definierte Labels (app, component, team, environment) und klare Ownership, sonst werden Selektoren unzuverlässig.
• Explizites Default Deny: Pro Namespace klare Baselines (Ingress/Egress getrennt) statt impliziter Annahmen.
• DNS bewusst erlauben: CoreDNS/NodeLocal DNSCache als Standardbaustein in jeder Egress-Strategie.
• Ausnahmen begrenzen: Keine „allow all egress“ ohne Ablaufdatum; externe Ziele als IPBlock/CIDR oder über definierte Egress-Gateways.
• Staging und Tests: Policies zuerst in einer repräsentativen Umgebung validieren; Regression-Tests für kritische Pfade automatisieren.
• Policy-as-Code: Versionierung, Reviews und CI-Validierung (z. B. Syntax/Schema, Policy-Linting) für reproduzierbare Änderungen.

Grenzfälle, die in der Praxis überraschen

• hostNetwork Pods: Pods im Host-Netzwerk umgehen viele Pod-Netzmechanismen; Policies greifen hier oft nicht wie erwartet.
• NodePorts und externe Zugriffe: Traffic kann über Node-IP und NodePort in den Cluster kommen; Ingress-Pfade müssen sauber modelliert werden.
• Sidecars/Proxies: Service-Mesh-Proxies verändern Datenpfade; Policies sollten den tatsächlichen Netzwerkpfad berücksichtigen.
• Managed Kubernetes Besonderheiten: Cloud-spezifische CNI-Implementierungen und Security Groups können zusätzliche Regeln erzwingen oder überschreiben.

Vom CNI bis zur OSI-Schicht: Eine praktikable mentale Landkarte

Wenn Sie Network Policies in Kubernetes nachhaltig betreiben wollen, hilft eine einfache Landkarte:

• CNI: Stellt Pod-Netzwerk her und setzt Policies technisch durch.
• NetworkPolicy (Kubernetes API): Definiert Absicht (Intent) auf Pod-/Namespace-Ebene, meist L3/L4.
• OSI-Layer 3/4: Hier entsteht die tatsächliche Durchsetzung (Routing + Transport).
• OSI-Layer 7: Ergänzende Kontrollen über Mesh/Gateway/WAF für inhaltsbasierte Regeln.
• Observability: Macht Durchsetzung sichtbar (Drops, Hits, Latenz, Fehler) und verhindert blindes Debugging.

Mit diesem Modell lassen sich Anforderungen („Wir brauchen Zero Trust“), technische Möglichkeiten („Unser CNI kann/kann nicht…“) und Betriebsrealität („Wir brauchen Telemetrie und Tests“) sauber zusammenbringen – und Network Policies werden vom YAML-Artefakt zur verlässlichen Sicherheits- und Reliability-Kontrolle im Cluster.

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.