Network Policy (Kubernetes)

Der "Deny-All" Standard (sollte jeder Namespace haben):

kind: NetworkPolicy
metadata:
  name: default-deny-all
spec:
  podSelector: {} # Alle Pods
  policyTypes:
  - Ingress # Eingehend verboten

Dann explizit öffnen ("Allow DB Access"):

spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend
    ports:
    - port: 5432

1. CNI Abhängigkeit

Network Policies sind nur ein Stück Papier (API-Objekt). Sie funktionieren nur, wenn das CNI-Plugin sie unterstützt.

• Calico, Cilium, Antrea: Ja, unterstützen es.
• Flannel (Standard): NEIN! Flannel ignoriert Policies einfach. Du fühlst dich sicher, bist aber offen. Prüfe immer deinen CNI-Provider!

2. Namespaces Selektoren

Wie erlaube ich Traffic von Namespace "monitoring" (Prometheus)? Du kannst namespaceSelector nutzen:

  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
            purpose: monitoring

Wichtig: Der Namespace "monitoring" muss das Label purpose=monitoring haben! Namen (name: monitoring) kann man oft nicht direkt selektieren (je nach K8s Version/CNI).

3. Egress Policies (Rausfunken)

Oft vergisst man den ausgehenden Verkehr (Egress). Ein gehackter Pod lädt Malware von evil-hacker.com nach. Mit Egress Policies kannst du sagen: "Dieser Pod darf nur DNS (UDP 53) und unsere interne API erreichen. Kein Internet!". Das erschwert Angreifern die "Command & Control" Kommunikation massiv.

Stateful Inspection (Conntrack)

Ein häufiges Missverständnis: Network Policies sind zustandsbehaftet (stateful). Wenn Pod A nach Pod B (Ingress Allow auf B) telefoniert, erlaubt das CNI-Plugin automatisch den Rückkanal (Antwortpakete von B an A). Du musst dafür auf A keine explizite Egress Allow Regel definieren! Der Linux-Kernel nutzt das Connection Tracking (conntrack Modul von iptables/eBPF). Er merkt sich die TCP-Session ("ESTABLISHED"), und lässt Antworten nativ durchs Nadelöhr zurückfließen.

eBPF und Cilium (Policy Enforcement ohne iptables)

Traditionelle CNI-Plugins (wie Calico im Standard-Modus oder Weave) übersetzen die K8s YAML-Policies in schier endlose und komplexe iptables-Listen auf den Worker-Nodes. Bei 5000 Pods bricht der Kernel beim Traversieren der Regeln (Linear Search) leistungstechnisch zusammen. Moderne Stacks nutzen Cilium mit eBPF. Hierbei wird die Policy-Logik als hochperformanter Bytecode direkt in den Kernel-Space in Hooks (wie XDP oder TC) injiziert. eBPF prüft Header-Pakete in O(1) Time-Complexity. Zudem ermöglicht Cilium "L7 Policies": Statt "Erlaube Port 80", kann eBPF sagen "Erlaube HTTP GET auf /api/v1, blockiere POST".

Ingress Controller vs Network Policy

Die Kante des Clusters (Ingress) ist besonders tückisch. Traffic von außen trifft oft auf einen ingress-nginx Controller-Pod. Wenn du nun auf deiner Backend-App sagst: "Ich erlaube nur Traffic vom Namespace frontend", blockst du versehentlich den Ingress-Controller aus, weil der im ingress-nginx Namespace lebt! Der Request stirbt mit einem mysteriösen Timeout. Lösung: Du musst bei Zero-Trust-Architekturen fast immer explizite Allow-Regeln für das Label deines Ingress-Controllers sowie für die Kube-DNS-Pods (UDP 53) in die Egress-Rules packen. Sonst kann dein Pod nicht einmal Namenstelefonbücher befragen.