Post-Quantum Kryptographie in Kubernetes: Praktischer Leitfaden

TL;DR

• Quantencomputer bedrohen RSA und ECC. Das NIST hat 2024 die ersten Post-Quantum-Standards finalisiert: ML-KEM (Kyber) fuer Key Encapsulation und ML-DSA (Dilithium) fuer Signaturen.
• Die groesste unmittelbare Gefahr ist "Harvest Now, Decrypt Later": Angreifer zeichnen heute verschluesselten Traffic auf und entschluesseln ihn spaeter.
• In Kubernetes betrifft das vor allem TLS-Verbindungen (Ingress, Service Mesh, API Server), Secrets at Rest und Container-Image-Signaturen.
• Der empfohlene Ansatz ist Hybrid-Kryptographie: klassische + PQC-Algorithmen parallel, um Abwaertskompatibilitaet zu wahren.
• Erste Schritte sind auditierbar und risikoarm umsetzbar, ohne den laufenden Betrieb zu gefaehrden.

Warum Post-Quantum Kryptographie jetzt relevant wird

Die meisten TLS-Verbindungen in Kubernetes-Clustern basieren auf ECDHE fuer den Schluesseltausch und ECDSA oder RSA fuer Signaturen. Beides ist durch Shors Algorithmus auf einem ausreichend grossen Quantencomputer brechbar.

Das klingt nach einem Problem fuer die ferne Zukunft. Ist es aber nicht -- aus zwei Gruenden:

1. Harvest Now, Decrypt Later (HNDL). Nachrichtendienste und andere Akteure zeichnen verschluesselten Netzwerktraffic auf. Wenn in 10-15 Jahren kryptographisch relevante Quantencomputer verfuegbar sind, koennen sie diesen Traffic entschluesseln. Fuer Daten mit langer Schutzfrist (Gesundheitsdaten, Staatsgeheimnisse, geistiges Eigentum) ist das Problem also schon heute real.

2. Migrationsdauer. Die Umstellung von kryptographischen Algorithmen in verteilten Systemen dauert Jahre. Die Migration von SHA-1 zu SHA-256 hat ueber ein Jahrzehnt gedauert. Wer erst handelt, wenn Quantencomputer existieren, handelt zu spaet.

Das BSI empfiehlt in seiner Technischen Richtlinie TR-02102 bereits den Einsatz von hybriden Verfahren fuer Systeme mit langer Nutzungsdauer. Das NIST hat im August 2024 die finalen Standards veroeffentlicht:

Wo PQC in Kubernetes greift

Ein Kubernetes-Cluster hat mehrere kryptographische Kontaktpunkte. Nicht alle sind gleich kritisch.

Die hoechste Prioritaet hat der Ingress, weil externer Traffic am einfachsten abzufangen ist. Danach folgen Service Mesh und API Server.

Schritt 1: Kryptographie-Inventar erstellen

Bevor Sie etwas aendern, muessen Sie wissen, was Sie haben. Ein Krypto-Audit beantwortet folgende Fragen:

• Welche TLS-Versionen und Cipher Suites sind an Ingress, API Server und Service Mesh konfiguriert?
• Welche Zertifikate sind im Einsatz und wer stellt sie aus (cert-manager Issuer, selbstsigniert, externe CA)?
• Ist etcd Encryption at Rest aktiviert? Mit welchem Algorithmus?
• Wie werden Secrets verwaltet (Kubernetes Secrets, External Secrets Operator, Vault)?
• Werden Container-Images signiert? Mit welchem Verfahren?

Das folgende Bash-Script prueft die TLS-Konfiguration am Ingress:

#!/bin/bash
# pqc-audit.sh -- Prueft TLS-Konfiguration an Kubernetes Ingress Endpoints

INGRESS_HOST="api.example.com"
INGRESS_PORT=443

echo "=== TLS-Konfiguration fuer $INGRESS_HOST ==="
echo ""

# Aktuelle Cipher Suite und Protokollversion anzeigen
echo "--- Ausgehandelte Verbindung ---"
openssl s_client -connect "$INGRESS_HOST:$INGRESS_PORT" -brief 2>/dev/null | head -5

echo ""
echo "--- Zertifikat-Details ---"
openssl s_client -connect "$INGRESS_HOST:$INGRESS_PORT" 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates -sigopt 2>/dev/null

echo ""
echo "--- Unterstuetzte Cipher Suites (TLS 1.3) ---"
openssl s_client -connect "$INGRESS_HOST:$INGRESS_PORT" \
  -tls1_3 -ciphersuites "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256" \
  2>/dev/null | grep "Cipher is"

echo ""
echo "--- Pruefe PQC-Readiness (X25519Kyber768) ---"
# Erfordert OpenSSL 3.5+ mit oqs-provider oder BoringSSL
openssl s_client -connect "$INGRESS_HOST:$INGRESS_PORT" \
  -groups X25519Kyber768Draft00 2>/dev/null | grep "Server Temp Key"

Das Script prueft, ob der Ingress-Endpoint bereits PQC-faehige Key-Exchange-Gruppen unterstuetzt. In der Regel ist das ohne Anpassung nicht der Fall.

Schritt 2: Hybrid-TLS am Ingress aktivieren

Der sicherste Migrationspfad ist Hybrid-Kryptographie. Dabei wird der Schluesseltausch gleichzeitig mit einem klassischen (z.B. X25519) und einem PQC-Algorithmus (z.B. ML-KEM-768) durchgefuehrt. Selbst wenn einer der beiden Algorithmen gebrochen wird, bleibt die Verbindung sicher.

NGINX Ingress mit PQC

NGINX unterstuetzt seit Version 1.27 (mit OpenSSL 3.5+) hybride Key-Exchange-Gruppen. Die Konfiguration erfolgt ueber eine ConfigMap:

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
data:
  # Aktiviere TLS 1.3 mit hybriden PQC-Gruppen
  ssl-protocols: "TLSv1.3"
  ssl-ciphers: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"
  # X25519Kyber768 ist der hybride Key-Exchange
  # Fallback auf X25519 fuer Clients ohne PQC-Support
  ssl-ecdh-curve: "X25519Kyber768Draft00:X25519:P-256"
  # Strikte Header
  ssl-prefer-server-ciphers: "true"
  hsts: "true"
  hsts-max-age: "31536000"
  hsts-include-subdomains: "true"

Clients, die den hybriden Key-Exchange nicht unterstuetzen, fallen automatisch auf X25519 zurueck. Es gibt also keinen Breaking Change.

cert-manager mit PQC-faehiger CA

Fuer PQC-Signaturen auf Zertifikaten muss die ausstellende CA PQC-Algorithmen unterstuetzen. Das ist aktuell noch experimentell. Der pragmatische Ansatz: Verwenden Sie weiterhin klassische Signaturen (ECDSA P-256) auf den Zertifikaten und schuetzen Sie den Schluesseltausch mit hybrider Kryptographie. Die Signatur-Migration kommt spaeter, wenn die Toolchain reifer ist.

Fuer Details zu cert-manager und Zertifikatsstrategien siehe Kubernetes Secrets Management mit Vault.

Schritt 3: Service Mesh mTLS haerten

Istio und Linkerd verschluesseln die interne Kommunikation standardmaessig mit mTLS. Beide nutzen dafuer Envoy Proxy (Istio) bzw. linkerd2-proxy. Die PQC-Unterstuetzung haengt von der eingesetzten TLS-Bibliothek ab.

Istio mit BoringSSL/Envoy: Envoy hat experimentellen Support fuer hybride Key-Exchange-Gruppen. Die Konfiguration erfolgt ueber ein EnvoyFilter:

apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: pqc-tls-config
  namespace: istio-system
spec:
  configPatches:
    - applyTo: CLUSTER
      match:
        context: ANY
      patch:
        operation: MERGE
        value:
          transport_socket:
            name: envoy.transport_sockets.tls
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
              common_tls_context:
                tls_params:
                  tls_minimum_protocol_version: TLSv1_3
                  tls_maximum_protocol_version: TLSv1_3
                  # ecdh_curves akzeptiert hybride Gruppen seit Envoy 1.30+
                  ecdh_curves:
                    - X25519Kyber768Draft00
                    - X25519

Testen Sie diese Konfiguration zuerst in einem Staging-Namespace. Service Mesh mTLS ist weniger exponiert als Ingress TLS, hat aber ein breiteres Blast Radius bei Fehlkonfigurationen.

Performance-Impact

PQC-Algorithmen erzeugen groessere Schluessel und erfordern mehr Rechenzeit. Das hat messbare Auswirkungen:

Der Latenz-Overhead ist in den meisten Szenarien vernachlaessigbar. Der groessere Einfluss liegt bei der Bandbreite durch groessere Schluessel und Signaturen, was besonders bei hohen Verbindungsraten (viele neue TLS-Handshakes pro Sekunde) relevant wird.

Fuer die Kapazitaetsplanung bei erhoehtem CPU-Bedarf durch PQC siehe Kubernetes Capacity Planning.

Krypto-Agilitaet sicherstellen

Der wichtigste Grundsatz ist nicht, sofort auf PQC umzusteigen, sondern die Faehigkeit aufzubauen, schnell umsteigen zu koennen. Das BSI nennt das "Krypto-Agilitaet".

Konkret bedeutet das:

• Zertifikats-Lifecycle automatisieren. Alle Zertifikate muessen ueber cert-manager oder eine vergleichbare Loesung verwaltet werden. Manuelle Zertifikate sind nicht austauschbar.
• TLS-Konfiguration zentralisieren. Cipher Suites und Key-Exchange-Gruppen sollten an einer Stelle konfiguriert werden (Ingress ConfigMap, Service Mesh Config), nicht in jeder Anwendung einzeln.
• Algorithmus-Wechsel testen. Fuehren Sie regelmaessig Rotationen der verwendeten Cipher Suites durch, auch ohne PQC. Das baut Vertrauen in den Migrationsprozess auf.
• Abhaengigkeiten kennen. Dokumentieren Sie, welche Bibliotheken (OpenSSL, BoringSSL, Go crypto) an welchen Stellen eingesetzt werden und welche PQC-Algorithmen sie unterstuetzen.

Fuer eine umfassende Verschluesselungsstrategie in Kubernetes siehe auch Kubernetes Encryption Strategies.

Priorisierter Migrationspfad

Nicht alles muss gleichzeitig passieren. Ein realistischer Zeitplan:

Quartal 1: Audit und Vorbereitung

• Krypto-Inventar erstellen (Script oben)
• OpenSSL/BoringSSL-Versionen auf allen Nodes pruefen
• cert-manager auf aktuelle Version bringen
• Team-Schulung zu PQC-Grundlagen

Quartal 2: Hybrid-TLS am Ingress

• NGINX Ingress oder Envoy Gateway mit hybriden Key-Exchange-Gruppen konfigurieren
• Performance-Tests unter Last durchfuehren
• Monitoring fuer PQC-spezifische Metriken einrichten (Handshake-Zeiten, Fallback-Rate)

Quartal 3: Service Mesh und API Server

• Istio/Linkerd mTLS auf hybride Gruppen umstellen
• API-Server-TLS-Konfiguration anpassen
• Vault Transit Engine auf PQC-faehige Schluessel evaluieren

Quartal 4: Signaturen und Storage

• Container-Image-Signing mit Cosign/Sigstore auf PQC-Signaturen evaluieren
• etcd Encryption at Rest mit PQC-Key-Wrapping testen
• Dokumentation und Playbooks finalisieren

etcd Encryption at Rest mit PQC-Key-Wrapping

Kubernetes speichert Secrets standardmaessig unverschluesselt in etcd. Mit Encryption at Rest werden sie verschluesselt abgelegt. Fuer PQC-Readiness kann das Key-Wrapping ueber einen externen KMS-Provider erfolgen, der PQC-Algorithmen unterstuetzt.

Die EncryptionConfiguration fuer den API Server sieht so aus:

apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      # Primaer: Externer KMS-Provider (z.B. Vault mit Transit Engine)
      - kms:
          apiVersion: v2
          name: vault-kms-provider
          endpoint: unix:///var/run/kms-provider/vault.sock
          timeout: 3s
      # Fallback: AES-GCM lokal (fuer den Fall, dass KMS nicht erreichbar ist)
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      # Letzter Fallback: Klartext (nur fuer Migration/Debugging)
      - identity: {}

Der KMS-Provider kommuniziert mit Vault's Transit Engine, die den Data Encryption Key (DEK) mit einem Key Encryption Key (KEK) verschluesselt. Wenn Vault PQC-faehige Algorithmen fuer den KEK unterstuetzt (experimenteller Support seit Vault 1.18+), ist die gesamte Kette quantenresistent.

Der Vorteil dieses Ansatzes: Die Encryption-at-Rest-Konfiguration im Kubernetes API Server muss sich nicht aendern. Nur der KMS-Backend-Algorithmus wird ausgetauscht. Das ist Krypto-Agilitaet in der Praxis.

Fuer die grundlegende Einrichtung von Vault in Kubernetes siehe Kubernetes Secrets Management mit Vault.

Haeufig gemachte Fehler

PQC-only statt hybrid. Wer nur auf PQC-Algorithmen setzt, verliert Kompatibilitaet mit Clients und Tools, die noch keinen PQC-Support haben. Hybrid ist der einzig sinnvolle Weg in der Uebergangsphase.

Algorithmen selbst waehlen. Verwenden Sie ausschliesslich die NIST-standardisierten Algorithmen (ML-KEM, ML-DSA, SLH-DSA). Experimentelle oder nicht-standardisierte Verfahren koennen Schwachstellen enthalten.

Nur TLS betrachten. PQC betrifft auch SSH-Schluessel fuer Node-Zugang, VPN-Verbindungen zwischen Standorten und Backup-Verschluesselung. Diese Punkte werden oft vergessen.

Keine Performance-Tests. PQC-Overhead ist messbar. Ohne Tests unter realistischer Last riskieren Sie Ueberraschungen in der Produktion. Der Artikel Kubernetes Performance Optimization gibt Hinweise zur systematischen Performance-Analyse.

Zusammenfassung

Post-Quantum-Kryptographie ist kein Zukunftsthema mehr, sondern eine Aufgabe, die jetzt begonnen werden muss -- nicht wegen eines unmittelbaren Angriffs, sondern wegen der Migrationsdauer und des HNDL-Risikos. Kubernetes bietet durch seine zentrale TLS-Terminierung (Ingress, Service Mesh) gute Ansatzpunkte fuer eine schrittweise Migration.

Der pragmatische Ansatz: Starten Sie mit einem Krypto-Audit, aktivieren Sie hybriden Key-Exchange am Ingress und bauen Sie von dort aus Krypto-Agilitaet auf. Die Tools dafuer existieren. Es fehlt in den meisten Organisationen nicht an Technologie, sondern an Priorisierung.

Wenn Sie Unterstuetzung bei der Planung oder Umsetzung Ihrer PQC-Migration benoetigen, stehen wir Ihnen gerne zur Verfuegung. Alle Details finden Sie auf unserer Kontaktseite.