Kubernetes Network Policies: Netzwerksicherheit im Cluster richtig umsetzen

Kubernetes erlaubt standardmäßig jede Pod-zu-Pod-Kommunikation im Cluster. Ohne Network Policies kann ein kompromittierter Workload lateral auf Datenbanken, interne APIs oder Secrets zugreifen — ohne dass eine Firewall oder ein Monitoring-System das bemerkt. Für Unternehmen im DACH-Raum, die unter DSGVO oder branchenspezifischen Compliance-Vorgaben arbeiten, ist das ein konkretes Risiko, kein theoretisches.

Was sind Network Policies?

Eine Network Policy ist eine Kubernetes-Ressource, die auf Layer 3/4 definiert, welche Pods miteinander kommunizieren dürfen — sowohl eingehend (Ingress) als auch ausgehend (Egress). Die Regeln werden über Label-Selektoren auf Pods angewendet und durch das CNI (Container Network Interface) des Clusters durchgesetzt.

Wichtig: Network Policies sind additiv. Sobald mindestens eine Policy auf einen Pod greift, wird jeglicher nicht explizit erlaubter Traffic abgelehnt. Existiert keine Policy, ist der Pod uneingeschränkt erreichbar.

Voraussetzung: CNI-Unterstützung

Nicht jedes CNI setzt Network Policies durch. Flannel ignoriert sie vollständig. Produktionsrelevante Optionen für DACH-Umgebungen sind:

• Cilium — eBPF-basiert, unterstützt zusätzlich Layer-7-Policies (HTTP, gRPC). Empfehlenswert für neue Cluster.
• Calico — weit verbreitet, stabile Network-Policy-Unterstützung, zusätzlich GlobalNetworkPolicy als CRD.
• Weave Net — unterstützt Standard-Network-Policies, wird aber kaum noch aktiv weiterentwickelt.

Managed-Kubernetes-Dienste wie EKS, GKE und AKS liefern CNIs mit, die Network Policies unterstützen — aber die Konfiguration muss explizit aktiviert werden (z. B. bei EKS: VPC CNI + Network Policy Controller).

Die Default-Deny-Strategie

Der sicherste Ausgangspunkt ist eine Default-Deny-Policy pro Namespace, die sämtlichen Ingress- und Egress-Traffic blockiert. Anschließend werden nur die tatsächlich benötigten Verbindungen explizit freigegeben.

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

Diese Policy betrifft alle Pods im Namespace production. Ein leererpodSelector bedeutet: alle Pods. Da weder Ingress- noch Egress-Regeln definiert sind, wird jeglicher Traffic verweigert.

Gezielten Traffic freigeben: Beispiele

Nach dem Default-Deny werden benötigte Verbindungen schrittweise erlaubt. Typisches Muster für eine Frontend-zu-Backend-Verbindung:

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

Nur Pods mit dem Label app: frontend dürfen den Backend-Pod auf Port 8080 erreichen. Alle anderen Verbindungen — auch aus demselben Namespace — werden blockiert.

Für Datenbankzugriffe empfiehlt sich zusätzlich die Einschränkung auf einen dedizierten Namespace, damit Staging-Umgebungen nicht versehentlich die Produktionsdatenbank erreichen:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: postgres
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: production
          podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Egress: DNS nicht vergessen

Ein häufiger Fehler bei Default-Deny-Egress-Policies: DNS-Auflösung bricht zusammen, weil Port 53 (UDP/TCP) zum kube-dns-Service nicht erlaubt ist. Das führt zu schwer debuggbaren Fehlern, bei denen Pods zwar erreichbar sind, aber externe Hostnamen nicht auflösen können.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  namespace: production
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

Häufige Fehler und wie man sie vermeidet

1. AND- statt OR-Logik bei kombinierten Selektoren: Wenn namespaceSelector und podSelector in einem gemeinsamen from-Eintrag stehen, wird AND-Logik angewendet (Pod muss in diesem Namespace UND dieses Label haben). Separate Einträge erzeugen OR-Logik. Dieser Unterschied ist in der YAML-Einrückung kaum sichtbar und verursacht regelmäßig Sicherheitslücken.

2. Kein Monitoring der Policy-Effekte: Network Policies erzeugen standardmäßig keine Logs. Ohne CNI-spezifisches Flow-Logging (Cilium Hubble, Calico Flow Logs) ist nicht erkennbar, welcher Traffic abgelehnt wird. Das erschwert Debugging und Incident-Response erheblich.

3. Policies nur im App-Namespace, nicht im System-Namespace: Workloads in kube-system oder dem Ingress-Namespace bleiben oft ungeschützt, obwohl sie privilegierten Zugriff haben. Eine vollständige Absicherung umfasst alle Namespaces.

4. Label-Drift: Wenn Deployments ihre Labels ändern (z. B. durch Helm-Upgrades), greifen Network-Policy-Selektoren nicht mehr. Labels und Policies müssen gemeinsam versioniert werden — idealerweise im selben GitOps-Repository.

Network Policies im GitOps-Kontext

Network Policies gehören in dasselbe Git-Repository wie die Applikationsmanifeste. Änderungen an einem Deployment sollten immer geprüft werden, ob bestehende Policies noch passen. In einer FluxCD- oder ArgoCD-gesteuerten Umgebung lassen sich Policies als Teil eines Helm-Charts oder Kustomize-Overlays verwalten und auf Umgebungen anwenden.

Policy-as-Code-Werkzeuge wie Kyverno ergänzen Network Policies sinnvoll: Kyverno kann erzwingen, dass jeder neue Namespace automatisch eine Default-Deny-Policy erhält — ohne manuelle Intervention.

Abgrenzung: Was Network Policies nicht leisten

Network Policies operieren auf Layer 3/4 und kennen keine Applikationsprotokolle. Sie können nicht prüfen, ob ein HTTP-Request eine bestimmte URL aufruft oder ob ein TLS-Zertifikat gültig ist. Für Layer-7-Kontrolle braucht es entweder Cilium mit L7-Policies oder ein Service Mesh (Istio, Linkerd). Für Secrets-Schutz, RBAC und Pod-Isolation sind zusätzlich Pod Security Standards und OPA/Kyverno-Admission-Controller notwendig — Network Policies sind eine Schicht im Defense-in-Depth-Modell, nicht die einzige.

Fazit

Network Policies sind das Fundament jeder ernsthaften Kubernetes-Sicherheitsstrategie. Sie sind deklarativ, versionierbar und CNI-nativ — ohne zusätzliche Abhängigkeiten. Der Aufwand für eine Default-Deny-Basis mit gezielten Freigaben ist überschaubar; der Sicherheitsgewinn ist erheblich. Wer diesen Schritt überspringt, betreibt de facto ein flaches Netzwerk im Cluster — unabhängig davon, wie gut die Perimeter-Firewall konfiguriert ist.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.