Zero-Trust Kubernetes Architektur: Vertraue niemandem in deinem Cluster

TL;DR

• Zero Trust bedeutet: Kein Pod, kein Service und kein Benutzer wird automatisch als vertrauenswuerdig eingestuft -- auch nicht innerhalb des Clusters.
• Die drei Saeulen einer Zero-Trust-Kubernetes-Architektur: Network Policies (Mikrosegmentierung), mTLS (verschluesselte Service-zu-Service-Kommunikation) und Identity Verification (kryptografische Identitaet pro Workload).
• Default-Deny NetworkPolicies sind der erste und wichtigste Schritt -- sie kosten nichts und sind in 10 Minuten ausgerollt.
• Ein Service Mesh wie Istio oder Linkerd ergaenzt mTLS und feingranulare Autorisierung auf Layer 7.
• Fuer DSGVO, BSI IT-Grundschutz und NIS2 ist Zero Trust keine Option mehr, sondern wird zunehmend zur regulatorischen Erwartung.

Warum das klassische Perimeter-Modell in Kubernetes versagt

In traditionellen IT-Architekturen schuetzt eine Firewall das interne Netzwerk nach aussen. Innerhalb des Perimeters gilt: Wer drin ist, darf kommunizieren. Dieses Modell scheitert in Kubernetes fundamental:

• Pods sind ephemeral: IP-Adressen wechseln bei jedem Neustart. Firewall-Regeln auf IP-Basis sind wertlos.
• Namespaces sind keine Sicherheitsgrenze: Ohne NetworkPolicies koennen Pods ueber Namespace-Grenzen hinweg kommunizieren.
• Laterale Bewegung ist trivial: Ein kompromittierter Pod kann standardmaessig jeden anderen Pod im Cluster erreichen.
• Shared Infrastructure: Mehrere Teams und Anwendungen teilen sich denselben Cluster. Ein Breach in einer Anwendung gefaehrdet alle anderen.

Die Konsequenz: Perimeter-Security reicht nicht. Jede Kommunikation im Cluster muss explizit autorisiert werden.

Die drei Saeulen der Zero-Trust-Kubernetes-Architektur

Eine detaillierte Einfuehrung in RBAC und Zugriffskontrolle finden Sie in unserem Artikel Kubernetes RBAC im Unternehmen.

Saeule 1: Netzwerk-Mikrosegmentierung mit NetworkPolicies

Default-Deny als Ausgangspunkt

Der wichtigste Einzelschritt fuer Zero Trust in Kubernetes: Eine Default-Deny-Policy pro Namespace. Damit wird saemtlicher Ingress- und Egress-Traffic blockiert, sofern er nicht durch eine weitere Policy explizit erlaubt wird.

# Default-Deny fuer den Namespace "produktion"
# Blockiert allen eingehenden und ausgehenden Traffic
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: produktion
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Nach dem Ausrollen dieser Policy kann kein Pod im Namespace produktion mehr kommunizieren -- weder eingehend noch ausgehend. Jetzt muessen Sie explizit erlauben, was erlaubt sein soll.

Gezielter Traffic erlauben

Im naechsten Schritt definieren Sie Allow-Policies fuer legitime Kommunikationspfade. Das folgende Beispiel erlaubt dem Frontend, das Backend auf Port 8080 zu erreichen, und dem Backend, die Datenbank auf Port 5432 anzusprechen:

# Frontend darf mit Backend kommunizieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: produktion
spec:
  podSelector:
    matchLabels:
      app: backend
      tier: api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
              tier: web
      ports:
        - protocol: TCP
          port: 8080
---
# Backend darf mit der Datenbank kommunizieren
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-database
  namespace: produktion
spec:
  podSelector:
    matchLabels:
      app: database
      tier: data
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: backend
              tier: api
      ports:
        - protocol: TCP
          port: 5432

Wichtig: Das Frontend kann die Datenbank nicht direkt erreichen. Jeder Kommunikationspfad ist explizit definiert. Das entspricht dem Zero-Trust-Prinzip der minimalen Berechtigung.

DNS-Egress nicht vergessen

Ein haeufiger Fehler: Nach dem Default-Deny funktioniert auch DNS nicht mehr. Pods koennen Services nicht mehr per Name aufloesen. Sie muessen DNS-Traffic explizit erlauben:

# DNS-Aufloesung fuer alle Pods im Namespace erlauben
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns-egress
  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

Weitere Details zur Egress-Filterung finden Sie in unserem Artikel Kubernetes Egress Filtering.

Saeule 2: mTLS -- verschluesselte und authentifizierte Kommunikation

NetworkPolicies kontrollieren, welcher Traffic fliessen darf. Aber sie schuetzen nicht den Inhalt der Kommunikation. Innerhalb des Cluster-Netzwerks ist der Traffic standardmaessig unverschluesselt. Ein Angreifer mit Zugriff auf das Node-Netzwerk kann Daten mitlesen.

Mutual TLS (mTLS) loest dieses Problem: Beide Seiten einer Verbindung authentifizieren sich gegenseitig mit Zertifikaten und verschluesseln den gesamten Traffic.

mTLS mit einem Service Mesh

Ein Service Mesh wie Istio oder Linkerd implementiert mTLS transparent fuer alle Services. Die Anwendungen selbst muessen nicht angepasst werden -- das Mesh injiziert Sidecar-Proxys, die die Verschluesselung uebernehmen.

Einen detaillierten Vergleich finden Sie in unserem Artikel Istio vs. Linkerd Vergleich.

Istio PeerAuthentication: mTLS erzwingen

# mTLS clusterweit im STRICT-Modus erzwingen
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
---
# Autorisierung: Nur Frontend darf Backend aufrufen
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-access
  namespace: produktion
spec:
  selector:
    matchLabels:
      app: backend
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "cluster.local/ns/produktion/sa/frontend-sa"
      to:
        - operation:
            methods: ["GET", "POST"]
            paths: ["/api/*"]

Mit STRICT-mTLS wird jede unverschluesselte Verbindung abgelehnt. Die AuthorizationPolicy geht noch weiter: Sie erlaubt den Zugriff auf das Backend nur vom ServiceAccount frontend-sa und nur auf bestimmte HTTP-Methoden und Pfade.

Saeule 3: Identity Verification und Least Privilege

Workload-Identitaet mit SPIFFE

In einer Zero-Trust-Architektur reicht eine IP-Adresse nicht als Identitaet. Jeder Workload braucht eine kryptografisch verifizierbare Identitaet. SPIFFE (Secure Production Identity Framework For Everyone) standardisiert diesen Ansatz.

Jeder Workload erhaelt eine SPIFFE ID im Format:

spiffe://cluster.local/ns/produktion/sa/backend-service

Diese Identitaet ist an ein X.509-Zertifikat gebunden, das automatisch rotiert wird. Service Meshes wie Istio implementieren SPIFFE nativ.

Pod Security Standards durchsetzen

Zero Trust bedeutet auch: Container laufen mit minimalen Berechtigungen. Kubernetes Pod Security Standards definieren drei Profile:

Fuer Zero Trust sollte das Profil restricted der Standard sein. Erzwingen Sie dies mit einer Kyverno-Policy:

# Kyverno Policy: Nur Restricted Pod Security Standard erlauben
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: enforce-restricted-pss
spec:
  validationFailureAction: Enforce
  background: true
  rules:
    - name: restrict-privilege-escalation
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Privilege Escalation ist nicht erlaubt. Setzen Sie allowPrivilegeEscalation auf false."
        pattern:
          spec:
            containers:
              - securityContext:
                  allowPrivilegeEscalation: false
                  runAsNonRoot: true
                  capabilities:
                    drop:
                      - ALL
    - name: restrict-host-namespaces
      match:
        any:
          - resources:
              kinds:
                - Pod
      validate:
        message: "Host-Namespaces (hostNetwork, hostPID, hostIPC) sind nicht erlaubt."
        pattern:
          spec:
            hostNetwork: false
            hostPID: false
            hostIPC: false

Mehr zur automatisierten Compliance-Durchsetzung mit Policy-as-Code finden Sie im Artikel Kubernetes Compliance ohne Security-Team.

Implementierungsfahrplan: Zero Trust in 4 Phasen

Der Weg zu Zero Trust ist ein iterativer Prozess. Versuchen Sie nicht, alles auf einmal umzusetzen. Der folgende Fahrplan hat sich in der Praxis bewaehrt:

Phase 1: Sichtbarkeit (Woche 1-2)

• Audit-Logging aktivieren und alle API-Aufrufe protokollieren
• Netzwerk-Traffic mit Hubble (Cilium) oder Kiali (Istio) visualisieren
• Bestehende RBAC-Konfiguration analysieren und ueberprivilegierte Rollen identifizieren
• Bestandsaufnahme aller Service-zu-Service-Kommunikationspfade

Phase 2: Netzwerk-Segmentierung (Woche 3-4)

• Default-Deny NetworkPolicies in allen Namespaces ausrollen
• Allow-Policies fuer dokumentierte Kommunikationspfade erstellen
• DNS-Egress-Policies konfigurieren
• Monitoring auf blockierten Traffic einrichten (damit Sie sehen, wenn eine Policy zu restriktiv ist)

Phase 3: mTLS und Verschluesselung (Woche 5-8)

• Service Mesh in Staging-Umgebung installieren
• mTLS zunaechst im PERMISSIVE-Modus aktivieren (erlaubt verschluesselt und unverschluesselt)
• Schrittweise auf STRICT-Modus migrieren, Namespace fuer Namespace
• AuthorizationPolicies fuer kritische Services definieren

Phase 4: Continuous Verification (Woche 9-12)

• Runtime-Security mit Falco fuer Anomalieerkennung einrichten
• Kyverno/OPA-Policies fuer Pod Security Standards automatisieren
• Automatisierte Compliance-Reports generieren
• Incident-Response-Prozesse fuer Security-Events definieren

Zero Trust und deutsche Compliance-Anforderungen

Zero Trust ist nicht nur ein technisches Konzept -- es adressiert direkt regulatorische Anforderungen, die fuer deutsche Unternehmen gelten:

Fuer eine umfassende Uebersicht der Compliance-Anforderungen lesen Sie unseren Artikel Kubernetes DSGVO-Compliance: Checkliste fuer deutsche Unternehmen.

Haeufige Fehler bei der Zero-Trust-Implementierung

1. NetworkPolicies ohne Monitoring ausrollen Wenn Sie Default-Deny aktivieren, ohne den blockierten Traffic zu ueberwachen, brechen Sie unbekannte Abhaengigkeiten. Aktivieren Sie zuerst Netzwerk-Monitoring (Hubble, Cilium) und analysieren Sie die tatsaechlichen Kommunikationspfade.

2. mTLS im STRICT-Modus ohne Uebergangsphase Der Wechsel von unverschluesselt auf STRICT-mTLS muss schrittweise erfolgen. Nutzen Sie den PERMISSIVE-Modus als Uebergang, um sicherzustellen, dass alle Services korrekt konfiguriert sind.

3. Zu breite RBAC-Rollen beibehalten Zero Trust im Netzwerk bringt wenig, wenn ServiceAccounts weiterhin cluster-admin-Berechtigungen haben. RBAC-Haertung gehoert zum Gesamtkonzept.

4. Externe Abhaengigkeiten vergessen Zero Trust endet nicht an der Cluster-Grenze. Egress-Traffic zu externen APIs, Datenbanken und SaaS-Diensten muss ebenfalls kontrolliert und verschluesselt werden.

Tooling-Uebersicht fuer Zero Trust in Kubernetes

Fazit: Zero Trust ist ein Prozess, kein Produkt

Zero Trust in Kubernetes ist kein einmaliges Projekt, das Sie abschliessen und abhaken. Es ist eine Sicherheitsstrategie, die sich mit Ihrem Cluster weiterentwickelt. Beginnen Sie mit NetworkPolicies -- sie sind der schnellste Weg zu messbarer Sicherheitsverbesserung und erfordern weder zusaetzliche Tools noch Budget.

Die Kombination aus Netzwerk-Mikrosegmentierung, mTLS und konsequentem Least Privilege macht Ihre Kubernetes-Infrastruktur resilient gegen interne und externe Bedrohungen. Gleichzeitig erfuellen Sie damit zentrale Anforderungen von DSGVO, BSI IT-Grundschutz und NIS2.

Wenn Sie Ihre Kubernetes-Sicherheit umfassend haerten wollen, empfehlen wir als naechsten Schritt unseren Artikel Kubernetes Security Hardening: Die komplette Checkliste. Fuer den Aufbau einer souveraenen Infrastruktur lesen Sie Kubernetes Private Cloud: Sovereign Cloud fuer deutsche Unternehmen.

Weiterführende Artikel

• Kubernetes RBAC im Unternehmen -- Sichere Zugriffskontrolle implementieren
• Kubernetes Compliance: DSGVO und BSI -- Regulatorische Anforderungen umsetzen
• Kubernetes Security Hardening -- Die komplette Haertungs-Checkliste
• Kubernetes Compliance ohne Security-Team -- Automatisierte Compliance fuer kleine Teams
• Istio vs. Linkerd Vergleich -- Service Mesh fuer mTLS auswaehlen