Kubernetes Network Policies: Microsegmentierung im Cluster

Kubernetes-Cluster sind standardmäßig flache Netzwerke: Jeder Pod kann jeden anderen Pod direkt erreichen — namespace-übergreifend, ohne Einschränkung. Das ist für einen Entwicklungs-Laptop praktisch. Für einen Produktions-Cluster mit sensiblen Daten ist es ein erhebliches Risiko. Network Policies sind das native Mittel, diesen Zustand zu korrigieren. Sie werden in der Praxis jedoch häufig entweder gar nicht eingesetzt oder so grob konfiguriert, dass sie wenig Schutz bieten.

Was Network Policies leisten — und was nicht

Eine NetworkPolicy ist ein Kubernetes-Objekt, das eingehenden (Ingress) und ausgehenden (Egress) Traffic auf Pod-Ebene steuert. Die Selektoren basieren auf Pod-Labels, Namespace-Labels und IP-Blöcken. Entscheidend: Network Policies sind additive Allowlists. Sobald eine Policy auf einen Pod greift, wird aller nicht explizit erlaubter Traffic blockiert.

Was Network Policies nicht leisten: Sie sind kein Ersatz für Mutual TLS (mTLS), sie inspizieren keinen Layer-7-Traffic und sie schützen nicht vor kompromittierten Pods, die legitime Verbindungen missbrauchen. Sie sind ein notwendiger, aber kein hinreichender Baustein einer Cluster-Sicherheitsstrategie.

Das häufigste Missverständnis: Der CNI-Plugin-Vorbehalt

Network Policies sind eine Kubernetes-API — ihre Durchsetzung obliegt dem CNI-Plugin (Container Network Interface). Wer einen Cluster mit dem Standard-Plugin Flannel betreibt, schreibt Network Policy-Manifeste, die schlicht ignoriert werden. Flannel implementiert das NetworkPolicy-API nicht.

Unterstützte CNI-Plugins sind unter anderem Calico, Cilium, Weave Net und Antrea. In der DACH-Praxis hat sich Cilium als bevorzugte Wahl etabliert — es unterstützt nicht nur das Standard-NetworkPolicy-API, sondern erweitert es umCiliumNetworkPolicy mit Layer-7-Regeln (HTTP, gRPC, Kafka).

Default-Deny als Ausgangspunkt

Eine bewährte Strategie beginnt mit einer Default-Deny-Policy für jeden Namespace, die allen Ingress- und Egress-Traffic blockiert. Darauf aufbauend werden nur die tatsächlich benötigten Verbindungen explizit freigegeben.

# Namespace-weite Default-Deny (Ingress + Egress)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Dieser Ansatz erzwingt explizites Denken über Kommunikationspfade. Teams, die ihre Abhängigkeiten nicht dokumentiert haben, werden das spätestens beim ersten fehlgeschlagenen Deployment merken — was unangenehm, aber heilsam ist.

Microsegmentierung in der Praxis: Ein Beispiel

Angenommen, ein Namespace enthält drei Komponenten: ein Frontend, ein API-Backend und eine Datenbank. Die gewünschten Kommunikationspfade:

• Frontend → Backend (Port 8080)
• Backend → Datenbank (Port 5432)
• Kein direkter Zugriff vom Frontend auf die Datenbank
• Egress der Datenbank nur zu kube-dns (Port 53)

# Backend darf von Frontend erreicht werden
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
---
# Datenbank darf nur vom Backend erreicht werden
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
      ports:
        - protocol: TCP
          port: 5432

Cilium Network Policies: Mehr Kontrolle auf Layer 7

Das Standard-NetworkPolicy-API arbeitet auf Layer 3 und 4 (IP, Port, Protokoll). Cilium erweitert dies auf Layer 7. Damit lassen sich Regeln wie "Backend darf/api/v1/users aufrufen, aber nicht /admin" direkt in der Policy abbilden — ohne separates Service Mesh.

# CiliumNetworkPolicy mit HTTP-Regel
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-only
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: GET
                path: /api/v1/.*

Diese Granularität ist besonders relevant für Compliance-Anforderungen (BSI IT-Grundschutz, ISO 27001), bei denen nachgewiesen werden muss, welche Systeme auf welche Endpunkte zugreifen dürfen.

Network Policies testen und validieren

Manifeste zu schreiben ist eine Sache — zu verifizieren, dass sie korrekt durchgesetzt werden, eine andere. Drei Werkzeuge haben sich bewährt:

• netpol-lint / np-guard: Statische Analyse von Network Policy-Manifesten auf Lücken und Konflikte — ideal in der CI/CD-Pipeline.
• Cilium Hubble: Echtzeit-Netzwerkbeobachtung auf Flow-Ebene. Zeigt explizit, welcher Traffic von welcher Policy erlaubt oder verworfen wird.
• kubectl run netshoot: Ein temporärer Debug-Pod mit Netzwerkwerkzeugen (curl, nc, nmap), mit dem Konnektivität manuell überprüft werden kann.

Typische Fehler in Produktions-Clustern

In der Praxis begegnen uns vier Muster regelmäßig:

1. Kein CNI-Support: Cluster mit Flannel oder nicht-konformem CNI — alle Network Policies sind wirkungslos, ohne dass jemand es bemerkt.
2. Fehlende Egress-Policies: Teams sichern Ingress ab, vergessen aber Egress — kompromittierte Pods können ungehindert nach außen kommunizieren.
3. Zu breite Selektoren: podSelector: in einer Allow-Policy öffnet versehentlich den gesamten Namespace.
4. kube-dns nicht freigegeben: Nach Default-Deny schlägt DNS-Auflösung fehl. Die Egress-Policy muss Port 53 (UDP und TCP) zu kube-dns explizit erlauben.

Einordnung in eine umfassende Sicherheitsstrategie

Network Policies sind ein Baustein, kein Allheilmittel. Eine vollständige Kubernetes-Sicherheitsstrategie für den Mittelstand umfasst typischerweise:

• Network Policies (Microsegmentierung, dieser Artikel)
• Pod Security Standards / Kyverno-Policies (Laufzeitabsicherung)
• RBAC mit Least-Privilege-Prinzip
• Image-Scanning und Supply-Chain-Sicherheit (Cosign, Sigstore)
• Secrets-Management (External Secrets Operator, Vault)
• Audit-Logging und Anomalie-Erkennung (Falco)

Welche Maßnahmen in welcher Reihenfolge sinnvoll sind, hängt vom konkreten Cluster-Zustand, den Compliance-Anforderungen und der Teamgröße ab. Ein strukturierter Cluster-Audit ist der schnellste Weg, Prioritäten zu setzen.

Mehr erfahren: Kubernetes-Beratung oder Audit buchen.