TLS post-quantum ibrido su un ingress Kubernetes

In un cluster Kubernetes, il TLS post-quantum ibrido si configura nel punto in cui l'handshake termina realmente, quasi mai nel container applicativo. Questo punto è di solito il pod dell'ingress controller, un load balancer cloud posto davanti a esso oppure un sidecar di service mesh. Il lavoro si articola in quattro passaggi: individuare il vero punto di terminazione, verificare la versione della libreria TLS in esecuzione in quel punto, inserire un gruppo ibrido come X25519MLKEM768 prima di un gruppo classico nell'elenco delle preferenze, quindi verificare dall'esterno del cluster.

Passaggio 1: individuare dove termina davvero l'handshake

Capita spesso che i team configurino il componente sbagliato e concludano che il loro controller non supporta lo scambio di chiavi post-quantum. Ricostruite prima il percorso di un pacchetto client. Solo il componente che detiene la chiave privata e invia il ServerHello decide il gruppo di scambio di chiavi.

Confermate la topologia con comandi in sola lettura prima di modificare qualsiasi cosa:

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}'

Le annotazioni del load balancer sul Service del controller indicano se il livello cloud termina il TLS o lo lascia passare. Se lo termina, nessuna impostazione dell'ingress modificherà il gruppo negoziato.

Passaggio 2: verificare cosa supporta la libreria TLS del controller

I gruppi ibridi sono una proprietà dello stack TLS compilato nell'immagine del controller, non di Kubernetes. Per le build basate su OpenSSL, è richiesto OpenSSL 3.5 o successivo per i gruppi ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism). I data plane basati su BoringSSL, come Envoy, usano una propria nomenclatura dei gruppi e una propria matrice di supporto: consultate quindi le note di rilascio della versione esatta che utilizzate.

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

Se la versione è precedente alla 3.5, fermatevi qui e pianificate un aggiornamento del controller. Nessuna chiave di configurazione può abilitare un gruppo che la libreria non implementa.

I nomi dei gruppi e i codepoint IANA che potete legittimamente utilizzare sono pubblicati nel registro dei parametri TLS (iana.org):

• X25519MLKEM768 (0x11EC, 4588), oggi lo standard de facto per i browser, descritto nella nostra pagina su X25519MLKEM768.
• SecP256r1MLKEM768 (0x11EB, 4587) e SecP384r1MLKEM1024 (0x11ED, 4589), per gli ambienti che richiedono curve NIST.
• I gruppi ML-KEM puri MLKEM512, MLKEM768 e MLKEM1024 (512, 513, 514). Non sono ibridi: la maggior parte dei lettori non dovrebbe ancora distribuirli sull'edge pubblico.

L'accordo di chiavi ibrido per TLS 1.3 è specificato nella RFC 10024 (rfc-editor.org). ML-KEM stesso è FIPS 203, definitivo dal 13 agosto 2024 (csrc.nist.gov). Il gruppo pre-standard della bozza Kyber X25519Kyber768Draft00 (0x6399) è obsoleto: se compare in un punto qualsiasi della vostra configurazione, rimuovetelo.

Passaggio 3: impostare i gruppi, con un fallback classico

Per ogni connessione viene negoziato un solo gruppo di scambio di chiavi, e il server sceglie tra quelli offerti dal client. Elencare per primo un gruppo ibrido e dopo un gruppo classico è quindi sicuro per costruzione: i client che conoscono il gruppo ibrido lo utilizzano, i client meno recenti ripiegano su X25519 o P-256.

ingress-nginx

Il controller espone la chiave ConfigMap ssl-ecdh-curve, che corrisponde alla direttiva nginx ssl_ecdh_curve e viene passata alla libreria TLS come elenco ordinato di gruppi (il suo valore predefinito è auto). Verificate la chiave nella documentazione di riferimento della ConfigMap per la versione del controller che utilizzate, quindi applicate:

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"

Qui prime256v1 è il nome OpenSSL di secp256r1. Mantenere due gruppi classici dopo quello ibrido preserva i client TLS 1.2 e qualsiasi client TLS 1.3 che non implementa ML-KEM. La stessa logica di ordinamento si applica a un web server autonomo, come descritto nella nostra guida per abilitare ML-KEM su nginx, Apache, HAProxy e Caddy.

Altri controller e service mesh

Non copiate le annotazioni da un controller all'altro. Un'annotazione che il controller non riconosce viene ignorata senza alcun avviso, ed è questa la modalità di errore più pericolosa: il rollout sembra riuscito e nulla è cambiato. Il principio è identico ovunque, cambia l'interfaccia:

• I data plane basati su Envoy espongono parametri TLS che includono un elenco di curve ECDH. In una mesh, questo campo si raggiunge di solito tramite un meccanismo di patch avanzato anziché tramite un'API di primo livello: verificate quindi la documentazione della vostra mesh e della versione del proxy.
• I controller basati su HAProxy e Traefik impostano l'elenco dei gruppi nei propri oggetti di configurazione. Cercate la chiave esatta nella documentazione del controller per la vostra versione e convalidatela in staging.
• Se è un load balancer gestito a terminare il TLS, l'unica leva a vostra disposizione è la policy TLS del provider. Se non viene offerta alcuna policy ibrida, l'alternativa è spostare la terminazione all'interno del cluster dietro un servizio passthrough di livello 4: si tratta di una modifica architetturale che merita una revisione dedicata.

Per ora lasciate invariata la catena di certificati

Il traffico registrato è protetto unicamente dallo scambio di chiavi, ed è proprio questo il punto dell'attacco harvest now, decrypt later: un attaccante che archivia oggi il testo cifrato può decifrarlo in seguito se lo scambio di chiavi era classico. Il nostro articolo su harvest now, decrypt later spiega perché lo scambio di chiavi viene per primo. I certificati possono migrare in un secondo momento: le autorità di certificazione pubbliche emettono ancora certificati ECDSA e RSA, e le firme ML-DSA, standardizzate come FIPS 204, non sono ancora generalmente disponibili nelle catene TLS pubbliche. In questa fase mantenete invariato il vostro issuer cert-manager esistente.

Passaggio 4: verificare dall'esterno del cluster

Eseguite il test da una macchina sull'internet pubblico, attraverso lo stesso percorso seguito da un browser. Non verificate mai con kubectl port-forward: aggira il load balancer e l'edge, e può quindi mostrare un handshake ibrido che nessun client reale otterrà mai. Con OpenSSL 3.5 o successivo:

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'

Un esito positivo stampa il gruppo negoziato. Dimostrate poi che il fallback funziona ancora, il test che i team dimenticano:

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'

Ripetete entrambi i test per ogni hostname pubblico, compreso il dominio apex e qualsiasi host servito da una seconda ingress class o da un diverso provider di edge. Un cluster con due ingress class finisce spesso per essere migrato solo a metà. Cosa un test esterno può e non può mostrare è descritto nella nostra metodologia dello scanner.

Passaggio 5: distribuire e conservare le evidenze

1. Applicate la modifica prima in staging, su un controller che esegue lo stesso tag di immagine della produzione.
2. Promuovetela su un solo hostname di produzione o su una sola ingress class canary, non sull'intera flotta.
3. Monitorate gli errori di handshake TLS e la CPU del controller per almeno un ciclo operativo completo. Le key share ML-KEM sono più grandi di una share X25519, quindi i messaggi ClientHello e ServerHello aumentano di dimensione.
4. Tenete pronto il rollback: riportare la chiave ConfigMap al valore precedente ripristina il comportamento originario al reload successivo.
5. Registrate il risultato nel vostro inventario crittografico, con la data e l'host testato.

È in quest'ultimo passaggio che una modifica di piattaforma diventa un'evidenza di conformità. La corrispondenza seguente è la nostra lettura di come l'artefatto tecnico risponde al requisito, non una citazione dei testi. Si tratta di informazioni, non di consulenza legale.

Passaggio successivo

Una volta applicata la ConfigMap e superati i test in staging, confermate il risultato visibile dall'esterno: analizzate il vostro dominio con PQC Status per vedere quale gruppo di scambio di chiavi il vostro ingress negozia effettivamente, quali versioni di TLS offre e come si presenta la catena di certificati. Eseguite la scansione una volta per ogni hostname pubblico, prima e dopo ogni aggiornamento dell'immagine del controller, perché una modifica dell'immagine può riportarvi silenziosamente a un gruppo classico. Una scansione descrive soltanto la configurazione TLS visibile dall'esterno: non è una certificazione né un'attestazione di conformità.