Network Policies: Kubernetes-Traffic richtig absichern

TL;DR

Kubernetes erlaubt standardmäßig jede Kommunikation zwischen allen Pods -- ohne Ausnahme. Network Policies sind der einzige native Mechanismus, um Traffic auf Pod-Ebene einzuschränken. Starten Sie mit einer Default-Deny-Policy pro Namespace und erlauben Sie dann gezielt nur die nötigen Verbindungen. Ohne ein CNI-Plugin wie Calico oder Cilium werden Network Policies ignoriert.

Das Problem: Kubernetes ist standardmäßig offen

Jeder Pod kann jeden anderen Pod erreichen -- egal in welchem Namespace. Das ist bequem für die Entwicklung, aber ein Sicherheitsrisiko in Produktion.

# Test: Pod in namespace-a erreicht Pod in namespace-b
kubectl run test-pod --namespace=namespace-a --rm -it --image=busybox -- \
  wget -qO- http://backend-service.namespace-b.svc.cluster.local:8080
# Ergebnis: Verbindung funktioniert -- ohne jede Einschränkung

Ein kompromittierter Pod hat damit sofort Zugriff auf die gesamte Cluster-Kommunikation. Network Policies ändern das.

Voraussetzung: CNI-Plugin mit Network Policy Support

Die Kubernetes-API akzeptiert NetworkPolicy-Ressourcen immer -- aber ohne ein unterstützendes CNI-Plugin passiert nichts. Die Policy wird gespeichert, aber nicht durchgesetzt.

Prüfen Sie zuerst, welches CNI in Ihrem Cluster läuft:

kubectl get pods -n kube-system -l k8s-app=calico-node
kubectl get pods -n kube-system -l k8s-app=cilium

Schritt 1: Default-Deny als Baseline

Der wichtigste Schritt: Blockieren Sie allen Traffic in einem Namespace und erlauben Sie dann nur das Nötige.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: produktion
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Nach dem Anwenden kann kein Pod im Namespace produktion mehr kommunizieren. Das ist beabsichtigt. Jetzt bauen Sie gezielte Ausnahmen.

Schritt 2: DNS-Egress erlauben

Ein häufiger Fehler nach Default-Deny: DNS funktioniert nicht mehr. Pods können Services nicht mehr per Name auflösen. Diese Policy müssen Sie immer zusätzlich anlegen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: produktion
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

Schritt 3: Gezielten Traffic erlauben

Ingress von bestimmten Pods

Das Frontend soll das Backend auf Port 8080 erreichen dürfen -- sonst niemand:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: produktion
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Ingress aus einem anderen Namespace

Monitoring-Tools aus dem Namespace monitoring sollen Metriken scrapen dürfen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-scrape
  namespace: produktion
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: monitoring
          podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090

Beachten Sie: namespaceSelector und podSelector im selben from-Block bedeuten UND. In getrennten from-Blöcken bedeuten sie ODER. Dieser Unterschied ist eine häufige Fehlerquelle.

Egress einschränken

Das Backend soll nur die Datenbank auf Port 5432 erreichen und sonst keine ausgehenden Verbindungen haben:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-db-only
  namespace: produktion
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: postgres
      ports:
        - protocol: TCP
          port: 5432
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: kube-dns
      ports:
        - protocol: UDP
          port: 53

Policies testen mit netcat

Verlassen Sie sich nicht darauf, dass Ihre Policies korrekt sind -- testen Sie aktiv:

# Erlaubte Verbindung testen (sollte funktionieren)
kubectl run test-frontend --namespace=produktion --rm -it \
  --labels="app=frontend" --image=busybox -- \
  nc -zv backend-service 8080

# Blockierte Verbindung testen (sollte fehlschlagen)
kubectl run test-attacker --namespace=produktion --rm -it \
  --labels="app=attacker" --image=busybox -- \
  nc -zv backend-service 8080 -w 3
# Erwartete Ausgabe: Connection timed out

Calico vs. Cilium: Welches CNI für Network Policies?

Beide Plugins unterstützen die Standard-NetworkPolicy-API vollständig. Die Unterschiede liegen in den Extras:

Für reine Layer-3/4-Policies reichen beide. Wenn Sie HTTP-Pfade oder DNS-basierte Egress-Regeln brauchen, bietet Cilium im Open-Source-Bereich mehr.

Häufige Fehler vermeiden

1. AND vs. OR bei Selektoren verwechseln Zwei Selektoren im selben from-Block werden mit AND verknüpft. In getrennten from-Blöcken mit OR. Das führt regelmäßig zu Policies, die entweder zu viel oder zu wenig erlauben.

2. DNS-Egress vergessen Nach Default-Deny funktioniert keine Namensauflösung mehr. Ohne die DNS-Egress-Policy sind alle Services unerreichbar.

3. Policies ohne CNI-Support deployen Flannel unterstützt keine Network Policies. Die API akzeptiert die Ressource trotzdem -- sie wird nur nicht durchgesetzt. Prüfen Sie Ihr CNI-Plugin.

FAQ

Funktionieren Network Policies mit jedem CNI-Plugin?

Nein. Flannel ignoriert Network Policies komplett. Sie brauchen ein CNI wie Calico oder Cilium, das die Policy-Durchsetzung aktiv übernimmt.

Was passiert, wenn ich keine Network Policy definiere?

Ohne jede NetworkPolicy-Ressource ist aller Traffic erlaubt. Sobald mindestens eine Policy auf einen Pod matched, wird nur noch der in Policies definierte Traffic zugelassen.

Kann ich Network Policies pro Cluster statt pro Namespace definieren?

Die Standard-API kennt nur Namespace-scoped Policies. Calico bietet GlobalNetworkPolicy, Cilium bietet CiliumClusterwideNetworkPolicy als CRDs für clusterweite Regeln.

Wie debugge ich blockierten Traffic?

Nutzen Sie kubectl describe networkpolicy um die aktiven Policies zu sehen. Mit Cilium können Sie hubble observe für Echtzeit-Flow-Analyse verwenden. Bei Calico hilft calicoctl mit Flow-Logs.

Fazit

Network Policies sind der schnellste Weg zu besserer Kubernetes-Sicherheit. Sie kosten nichts, erfordern keine zusätzlichen Tools (vorausgesetzt, ein passendes CNI ist installiert) und lassen sich schrittweise einführen. Starten Sie mit Default-Deny in einem unkritischen Namespace, testen Sie mit netcat und erweitern Sie dann auf alle Namespaces.