Hybrides Post-Quantum-TLS an einem Kubernetes-Ingress

In einem Kubernetes-Cluster wird hybrides Post-Quantum-TLS dort konfiguriert, wo der Handshake tatsächlich endet, und das ist fast nie der Anwendungscontainer. Meist handelt es sich um den Pod des Ingress-Controllers, einen vorgelagerten Cloud-Load-Balancer oder einen Service-Mesh-Sidecar. Die Arbeit umfasst vier Schritte: den tatsächlichen Terminierungspunkt finden, die dort laufende Version der TLS-Bibliothek prüfen, eine hybride Gruppe wie X25519MLKEM768 in der Präferenzliste vor eine klassische Gruppe setzen und schließlich von außerhalb des Clusters verifizieren.

Schritt 1: Finden Sie heraus, wo der Handshake wirklich endet

Teams konfigurieren häufig die falsche Komponente und schließen daraus, dass ihr Controller keinen Post-Quantum-Schlüsselaustausch unterstützt. Bilden Sie zuerst den Weg eines Client-Pakets ab. Nur die Komponente, die den privaten Schlüssel besitzt und das ServerHello sendet, entscheidet über die Gruppe für den Schlüsselaustausch.

Bestätigen Sie die Topologie mit rein lesenden Befehlen, bevor Sie etwas ändern:

kubectl get ingress -A -o wide
kubectl -n ingress-nginx get svc -o wide
kubectl -n ingress-nginx get svc ingress-nginx-controller -o jsonpath='{.metadata.annotations}'

Die Load-Balancer-Annotationen am Service des Controllers zeigen Ihnen, ob die Cloud-Schicht TLS terminiert oder durchreicht. Terminiert sie, ändert keine Ingress-Einstellung die ausgehandelte Gruppe.

Schritt 2: Prüfen Sie, was die TLS-Bibliothek des Controllers unterstützt

Die hybriden Gruppen sind eine Eigenschaft des TLS-Stacks, der in das Controller-Image kompiliert ist, nicht von Kubernetes. Für OpenSSL-basierte Builds ist OpenSSL 3.5 oder neuer für die ML-KEM-Gruppen (Module-Lattice-Based Key-Encapsulation Mechanism) erforderlich. BoringSSL-basierte Data Planes wie Envoy verwenden eigene Gruppenbezeichnungen und eine eigene Unterstützungsmatrix. Lesen Sie daher die Release Notes für genau die Version, die Sie betreiben.

kubectl -n ingress-nginx exec deploy/ingress-nginx-controller -- openssl version

Ist diese Version älter als 3.5, halten Sie hier an und planen Sie ein Upgrade des Controllers. Kein Konfigurationsschlüssel kann eine Gruppe aktivieren, die die Bibliothek nicht implementiert.

Die Gruppennamen und IANA-Codepoints, die Sie legitimerweise verwenden können, sind im TLS-Parameter-Registry veröffentlicht (iana.org):

• X25519MLKEM768 (0x11EC, 4588), heute der De-facto-Standard in Browsern, beschrieben auf unserer Seite zu X25519MLKEM768.
• SecP256r1MLKEM768 (0x11EB, 4587) und SecP384r1MLKEM1024 (0x11ED, 4589), für Umgebungen, die NIST-Kurven verlangen.
• Reine ML-KEM-Gruppen MLKEM512, MLKEM768 und MLKEM1024 (512, 513, 514). Diese sind nicht hybrid: Die meisten Leser sollten sie noch nicht an der öffentlichen Edge einsetzen.

Die hybride Schlüsselvereinbarung für TLS 1.3 ist in RFC 10024 spezifiziert (rfc-editor.org). ML-KEM selbst ist FIPS 203, final seit dem 13. August 2024 (csrc.nist.gov). Die vorstandardisierte Kyber-Entwurfsgruppe X25519Kyber768Draft00 (0x6399) ist veraltet: Taucht sie irgendwo in Ihrer Konfiguration auf, entfernen Sie sie.

Schritt 3: Setzen Sie die Gruppen, mit klassischem Fallback

Pro Verbindung wird nur eine Gruppe für den Schlüsselaustausch ausgehandelt, und der Server wählt aus dem, was der Client angeboten hat. Eine hybride Gruppe zuerst und eine klassische Gruppe danach aufzuführen, ist daher konstruktionsbedingt sicher: Clients, die die hybride Gruppe kennen, nutzen sie, ältere Clients fallen auf X25519 oder P-256 zurück.

ingress-nginx

Der Controller stellt den ConfigMap-Schlüssel ssl-ecdh-curve bereit, der auf die nginx-Direktive ssl_ecdh_curve abgebildet und als geordnete Gruppenliste an die TLS-Bibliothek übergeben wird (sein Standardwert ist auto). Prüfen Sie den Schlüssel in der ConfigMap-Referenz für die von Ihnen betriebene Controller-Version und wenden Sie dann an:

apiVersion: v1
kind: ConfigMap
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
data:
  ssl-protocols: "TLSv1.3 TLSv1.2"
  ssl-ecdh-curve: "X25519MLKEM768:X25519:prime256v1"

Dabei ist prime256v1 die OpenSSL-Bezeichnung für secp256r1. Zwei klassische Gruppen nach der hybriden beizubehalten, sichert TLS-1.2-Clients sowie jeden TLS-1.3-Client ab, der ML-KEM nicht implementiert. Dieselbe Reihenfolgelogik gilt für einen eigenständigen Webserver, wie in unserem Leitfaden zum Aktivieren von ML-KEM auf nginx, Apache, HAProxy und Caddy beschrieben.

Andere Controller und Service Meshes

Kopieren Sie keine Annotationen zwischen Controllern. Eine Annotation, die der Controller nicht kennt, wird stillschweigend ignoriert, und das ist hier der gefährlichste Fehlerfall: Der Rollout wirkt erfolgreich, aber nichts hat sich geändert. Das Prinzip ist überall dasselbe, nur die Konfigurationsoberfläche unterscheidet sich:

• Envoy-basierte Data Planes stellen TLS-Parameter bereit, die eine Liste von ECDH-Kurven enthalten. In einem Mesh erreicht man dieses Feld meist über einen erweiterten Patch-Mechanismus statt über eine erstklassige API. Prüfen Sie daher die Dokumentation für Ihre Mesh- und Proxy-Version.
• HAProxy- und Traefik-basierte Controller setzen die Gruppenliste in ihren eigenen Konfigurationsobjekten. Schlagen Sie den genauen Schlüssel in der Controller-Dokumentation für Ihre Version nach und validieren Sie ihn in Staging.
• Terminiert ein verwalteter Load Balancer TLS, ist Ihr einziger Hebel die TLS-Richtlinie des Anbieters. Wird keine hybride Richtlinie angeboten, besteht die Alternative darin, die Terminierung hinter einem Layer-4-Passthrough-Service in den Cluster zu verlagern. Das ist eine Architekturänderung und verdient eine eigene Prüfung.

Lassen Sie die Zertifikatskette vorerst unverändert

Aufgezeichneter Verkehr ist allein durch den Schlüsselaustausch geschützt, und genau darum geht es bei „Harvest Now, Decrypt Later“: Ein Angreifer, der heute Chiffretext speichert, kann ihn später entschlüsseln, wenn der Schlüsselaustausch klassisch war. Unser Artikel zu Harvest Now, Decrypt Later erklärt, warum der Schlüsselaustausch an erster Stelle steht. Zertifikate können später migriert werden: Öffentliche Zertifizierungsstellen stellen weiterhin ECDSA- und RSA-Zertifikate aus, und ML-DSA-Signaturen, standardisiert als FIPS 204, sind in öffentlichen TLS-Ketten noch nicht allgemein verfügbar. Lassen Sie Ihren bestehenden cert-manager-Issuer in dieser Phase unverändert.

Schritt 4: Verifizieren Sie von außerhalb des Clusters

Testen Sie von einem Rechner im öffentlichen Internet, über denselben Weg, den ein Browser nimmt. Verifizieren Sie niemals mit kubectl port-forward: Damit umgehen Sie Load Balancer und Edge, sodass ein hybrider Handshake angezeigt werden kann, den kein echter Client je erhält. Mit OpenSSL 3.5 oder neuer:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Ein erfolgreiches Ergebnis gibt die ausgehandelte Gruppe aus. Weisen Sie anschließend nach, dass der Fallback weiterhin funktioniert. Diesen Test vergessen Teams häufig:

openssl s_client -connect www.example.com:443 -servername www.example.com \
  -groups X25519 </dev/null 2>/dev/null | grep -i 'Negotiated TLS1.3 group'

Wiederholen Sie beide Tests für jeden öffentlichen Hostnamen, einschließlich der Apex-Domain und jedes Hosts, der über eine zweite Ingress-Klasse oder einen anderen Edge-Anbieter ausgeliefert wird. Ein Cluster mit zwei Ingress-Klassen ist häufig nur zur Hälfte migriert. Was ein externer Test zeigen kann und was nicht, beschreibt unsere Scanner-Methodik.

Schritt 5: Ausrollen und Nachweise aufbewahren

1. Wenden Sie die Änderung zuerst in Staging an, auf einem Controller mit demselben Image-Tag wie in Produktion.
2. Übernehmen Sie sie in einen einzelnen Produktions-Hostnamen oder eine Canary-Ingress-Klasse, nicht in die gesamte Flotte.
3. Beobachten Sie TLS-Handshake-Fehler und die CPU-Last des Controllers über mindestens einen vollständigen Geschäftszyklus. ML-KEM-Key-Shares sind größer als ein X25519-Share, daher wachsen ClientHello- und ServerHello-Nachrichten.
4. Halten Sie das Rollback bereit: Wird der ConfigMap-Schlüssel auf seinen vorherigen Wert zurückgesetzt, ist beim nächsten Reload das alte Verhalten wiederhergestellt.
5. Dokumentieren Sie das Ergebnis in Ihrem kryptografischen Inventar, mit Datum und getestetem Host.

Mit diesem letzten Schritt wird eine Plattformänderung zum Compliance-Nachweis. Die folgende Zuordnung ist unsere Lesart, wie das technische Artefakt die Anforderung unterstützt, kein Zitat der Texte. Dies ist eine Information, keine Rechtsberatung.

Nächster Schritt

Sobald die ConfigMap angewendet ist und Ihre Staging-Tests bestanden sind, bestätigen Sie das von außen sichtbare Ergebnis: Scannen Sie Ihre Domain mit PQC Status, um zu sehen, welche Gruppe für den Schlüsselaustausch Ihr Ingress tatsächlich aushandelt, welche TLS-Versionen er anbietet und wie die Zertifikatskette aussieht. Führen Sie den Scan einmal pro öffentlichem Hostnamen aus, jeweils vor und nach jedem Upgrade des Controller-Images, denn ein Image-Wechsel kann Sie unbemerkt auf eine klassische Gruppe zurückwerfen. Ein Scan beschreibt ausschließlich die von außen sichtbare TLS-Konfiguration: Er ist weder eine Zertifizierung noch eine Compliance-Bestätigung.