ingress-nginx è morto a marzo e la migrazione la stai ancora rimandando

A marzo 2026 il progetto ingress-nginx di Kubernetes è stato ritirato secondo il calendario annunciato: repository archiviato in sola lettura, manutenzione conclusa, e da allora, parole testuali dell'annuncio ufficiale, "nessuna nuova release, nessun bugfix e nessun aggiornamento per risolvere eventuali vulnerabilità di sicurezza". Non parliamo di un componente di nicchia: il comunicato congiunto dei comitati di Kubernetes lo ha definito infrastruttura critica per circa metà degli ambienti cloud native. E qui sta il punto che rende questo pezzo necessario a fine ottobre, sette mesi dopo il ritiro: i deployment esistenti hanno continuato a funzionare, perché il ritiro di un progetto non spegne i suoi pod, e in una quota impressionante di cluster che ho visto quest'anno, in audit e subentri, ingress-nginx è ancora lì, in prima linea, a terminare il TLS di produzione. Nessun sintomo, nessun alert, nessun incidente: solo un contatore invisibile che conta i giorni fra oggi e la prossima CVE che nessuno correggerà. In questo articolo metto in fila quello che serve per chiudere la faccenda: quanto è grave davvero restare fermi, perché il progetto è morto (la storia insegna più della notizia), il confronto onesto fra le strade di migrazione disponibili, e la procedura che uso per spostare il traffico senza fermare niente.

Il mio cluster è ancora su ingress-nginx: quanto è grave?

La risposta onesta: oggi tutto funziona, ed è precisamente questo il problema. Un ingress controller non è un pacchetto qualunque: è il componente esposto a internet che riceve ogni richiesta in ingresso, termina il TLS con le tue chiavi private, e gira dentro il cluster con permessi che gli consentono di leggere Secret e parlare con l'API server. È la combinazione peggiore possibile su cui accumulare vulnerabilità non corrette: superficie esposta, materiale crittografico, privilegi. E non serve immaginare scenari teorici, perché la storia recente del progetto ha già fornito la dimostrazione pratica: la famiglia di vulnerabilità IngressNightmare del marzo 2025, con la CVE-2025-1974 in testa, CVSS 9.8, permetteva a un attaccante non autenticato di ottenere esecuzione di codice attraverso l'admission controller e da lì, leggendo i Secret, il controllo dell'intero cluster. Quella volta la patch arrivò in giornata. La prossima volta non arriverà: questa è l'intera differenza fra febbraio e aprile 2026, ed è irreversibile.

La verifica di esposizione richiede un minuto, e su un parco di cluster conviene farla adesso, a mente fredda:

kubectl get pods --all-namespaces | grep -i ingress-nginx
kubectl get ingressclass
kubectl get ingress --all-namespaces -o wide | head

Se il primo comando restituisce pod e il secondo una classe nginx gestita dal controller comunitario, sei nel perimetro. Attenzione a un equivoco che genera falsi negativi e falsi sensi di colpa in egual misura: il progetto ritirato è kubernetes/ingress-nginx, quello della comunità Kubernetes. Il controller nginxinc/kubernetes-ingress di F5 è un progetto diverso, vivo e mantenuto, con annotazioni e architettura proprie: se usi quello, questo articolo per te è una lettura preventiva, non un allarme. La confusione fra i due nomi, quasi identici, ha prodotto quest'anno una quantità notevole di valutazioni sbagliate in entrambe le direzioni.

Nel frattempo, mentre pianifichi la migrazione, due mitigazioni riducono la superficie senza risolvere il problema. La prima: verifica che l'admission webhook del controller, il vettore usato da IngressNightmare, non sia raggiungibile da dove non deve; un controllo su ValidatingWebhookConfiguration e una NetworkPolicy che ne limiti l'accesso al solo API server costano un'ora e chiudono la porta più famosa. La seconda: se davanti al cluster hai già un livello di filtraggio, un WAF, un reverse proxy di bordo, un load balancer del provider con regole, è il momento di usarlo sul serio, restringendo ciò che raggiunge il controller. Sono cerotti, e vanno chiamati così: rendono meno probabile il disastro nel trimestre in cui migri, non sostituiscono la migrazione.

Perché è morto un progetto che usava mezzo mondo

La cronologia è breve e istruttiva. L'11 novembre 2025 SIG Network e il Security Response Committee annunciano il ritiro: manutenzione best-effort fino a marzo 2026, poi lo stop completo, con la raccomandazione esplicita di migrare a Gateway API, "il rimpiazzo moderno di Ingress". Il 29 gennaio 2026 arriva un secondo comunicato, firmato dai comitati Steering e Security Response insieme, con un tono che nella storia di Kubernetes non ha molti precedenti: il messaggio non può essere "ignorato, minimizzato o lasciato all'ultimo minuto", ed è "imperativo controllare i cluster adesso". A marzo, il ritiro effettivo. La causa non è tecnica ma umana: il componente che serviva metà del cloud native era mantenuto da una o due persone, la sera e nei fine settimana, e anni di appelli per nuovi maintainer non hanno prodotto nulla. Nemmeno il successore designato, InGate, è mai maturato: è stato ritirato anche lui, prima ancora di nascere davvero.

La lezione di ingress-nginx non riguarda nginx: riguarda il metodo con cui scegli le dipendenze critiche. "Lo usano tutti" non è un indicatore di sostenibilità; il numero di maintainer attivi, sì. Mezzo ecosistema ha costruito la propria porta d'ingresso su un progetto tenuto in piedi da due volontari, e nessuno se n'è accorto finché i volontari non hanno detto basta.

C'è anche una lettura più larga, che riguarda chiunque costruisca su open source, cioè tutti. Le aziende che per anni hanno messo ingress-nginx in produzione senza contribuire un'ora di lavoro o un euro al progetto non hanno fatto niente di illecito: hanno fatto quello che l'ecosistema incoraggia. Ma il conto della sostenibilità arriva sempre, e quando arriva non è negoziabile; era già successo con altri progetti-infrastruttura tenuti in piedi da volontari, e risuccederà. La contromisura pratica, alla portata di qualunque PMI, non è finanziare tutto ciò che si usa: è sapere cosa si usa, con un inventario delle dipendenze critiche che includa lo stato di manutenzione, l'iscrizione agli annunci di sicurezza dei progetti da cui dipendi, e una domanda fissa nelle valutazioni tecnologiche: "chi mantiene questa cosa, e in quanti sono?".

Questo genere di censimento delle dipendenze, con il loro stato di manutenzione reale, è una delle prime cose che guardo negli audit infrastrutturali: nel mio profilo professionale trovi come lavoro su architetture container e migrazioni di produzione per le PMI.

Le strade di migrazione, a confronto

Non esiste un rimpiazzo drop-in, e chiunque te lo prometta sta semplificando troppo: ingress-nginx aveva esteso l'API Ingress con decine di annotazioni proprie, snippet di configurazione e comportamenti impliciti che ogni alternativa gestisce a modo suo. Le opzioni reali sono quattro, più una falsa:

La mia gerarchia di raccomandazione, per i cluster che seguo: se il cluster ha davanti anni di vita, la strada è Gateway API, perché è il successore dichiarato dell'API Ingress ed è dove va l'investimento dell'intero ecosistema. Vale la pena spendere due righe sul perché il modello è migliore, al di là della necessità: l'API Ingress schiacciava tutto in una risorsa sola, e ogni comportamento non previsto finiva in annotazioni proprietarie del controller, il che è esattamente il motivo per cui oggi migrare è faticoso. Il Gateway API separa i ruoli: la GatewayClass la sceglie chi gestisce l'infrastruttura, il Gateway (indirizzi, porte, certificati) lo governa il team piattaforma, e le HTTPRoute vivono nei namespace delle applicazioni, dove i team di sviluppo le gestiscono in autonomia senza poter toccare ciò che non li riguarda. Per un'organizzazione con più team è un guadagno di governance, non solo di igiene tecnica; e le funzionalità che su ingress-nginx richiedevano annotazioni e snippet, redirect, riscritture, header, traffic splitting, nel Gateway API sono campi tipizzati della specifica, validabili e portabili fra controller diversi. Se invece serve uscire dal rischio in settimane, il ponte via Traefik o HAProxy su API Ingress è legittimo: l'importante è chiamarlo ponte, metterlo per iscritto come tale, e non lasciare che il provvisorio diventi il prossimo legacy. Il fork mantenuto è la scialuppa per chi ha vincoli veri (ambienti regolati, finestre di cambio rare): compra mesi, non anni.

La procedura che non ferma la produzione

La migrazione di un ingress controller ha una proprietà che la rende meno spaventosa di quanto sembri: si può fare in parallelo, senza toccare quello vecchio fino all'ultimo giorno. La sequenza che applico è in cinque passi. Primo, il censimento: estrarre tutte le risorse Ingress e le annotazioni effettivamente usate (kubectl get ingress -A -o yaml, più un grep sulle annotazioni nginx.ingress.kubernetes.io/), perché il costo della migrazione non lo decide il numero di servizi ma il numero di comportamenti speciali: rewrite, snippet, auth esterne, websocket, timeouts custom. Secondo, la conversione assistita: il progetto Kubernetes ha rilasciato a marzo 2026 ingress2gateway 1.0, lo strumento ufficiale che traduce le risorse Ingress, annotazioni comprese dove possibile, in risorse Gateway API; non copre tutto, ma trasforma la pagina bianca in una revisione. Terzo, il doppio binario: il controller nuovo si installa accanto al vecchio, con il suo IP o il suo LoadBalancer, e si collauda con host di test reali, certificati inclusi. Quarto, lo spostamento del traffico per hostname, via DNS, un servizio alla volta, cominciando da quello meno critico: ogni spostamento è reversibile abbassando un TTL. Quinto, lo smantellamento del vecchio controller solo quando il traffico è a zero da giorni, e la rimozione delle sue RBAC e dei suoi Secret, che è la parte che tutti dimenticano.

Due dettagli operativi che decidono la differenza fra una migrazione liscia e una nottata. Il primo sono i certificati: se usi cert-manager, verifica prima dello switch che l'integrazione con il controller nuovo sia configurata e che il rinnovo funzioni davvero, con un certificato di staging emesso end-to-end; il momento in cui scopri che le challenge HTTP non passano più non deve essere la scadenza del certificato di produzione. Il secondo è l'osservabilità: durante il doppio binario tieni sotto gli occhi i log di accesso e i codici di risposta di entrambi i controller, perché la regressione tipica non è il servizio giù, è il redirect che si comporta diversamente o l'header che non arriva più, e si vede nei log molto prima che nei ticket.

Un'ultima nota di calendario, per chi ha rimandato tutto fin qui: se stai pianificando la finestra di manutenzione per questa migrazione, guarda anche la versione del cluster, perché Kubernetes 1.34 esce dal supporto il 27 ottobre 2026 e le due manutenzioni si combinano bene in un unico intervento pianificato. Su cluster piccoli, come quelli che ho descritto nel setup economico di Kubernetes su Hetzner Cloud, l'intera operazione sta comodamente in una giornata; e se il censimento ti fa scoprire che di Kubernetes, in fondo, non avevi nemmeno bisogno, non sarebbe la prima volta, ne ho scritto in quando Kubernetes ha senso per una PMI e quando è over-engineering.

Il ritiro di ingress-nginx è stato annunciato con quattro mesi di preavviso, comunicato due volte con un linguaggio che definire esplicito è poco, ed eseguito puntualmente: come evento di rischio, era il più prevedibile dell'anno. Eppure a fine ottobre i cluster che lo eseguono ancora si contano a mazzi, ed è la conferma di una regola che vale più di ogni tecnologia: le migrazioni non rimandate sono manutenzione, quelle rimandate diventano emergenze, e la differenza di costo fra le due è tipicamente un ordine di grandezza. Se il tuo cluster è fra quelli fermi al 2025 e vuoi una mano a scegliere la strada giusta e a percorrerla senza downtime, censimento, conversione, doppio binario e collaudo compresi, contattami per una consulenza: la finestra buona per farlo con calma è adesso, perché quella successiva la sceglie la prossima CVE.