La retraite d’ingress-nginx impose une migration vers Gateway API avant novembre 2026

12 novembre 2025. Kubernetes annonce, par la voix de SIG Network et du Security Response Committee, la retraite d’ingress-nginx. Mars 2026. La maintenance amont s’arrête, le dépôt passe en lecture seule. Novembre 2026. La dernière passerelle de correctifs, celle d’AKS Application Routing, expire. Pourquoi c’est important : un contrôleur d’entrée figé dans votre chemin de données L7 ne recevra plus jamais de correctif de sécurité — la migration vers Gateway API devient un chantier daté, pas une option.

Ce qui s’est réellement arrêté en mars 2026

La retraite a été annoncée dès le 12 novembre 2025 sur le blog des contributeurs Kubernetes, signée par Tabitha Sable au nom du comité de pilotage sécurité. Le texte est sans ambiguïté : « meilleur effort » de maintenance jusqu’en mars 2026, puis plus aucune publication, plus aucun correctif, plus aucun fix de faille. Les dépôts GitHub deviennent en lecture seule, mais les artefacts existants — charts Helm et images de conteneur — restent disponibles.

Il faut lire ce « restent disponibles » pour ce qu’il est : une contrainte de compatibilité, pas une bouée de sauvetage. Votre déploiement actuel continue de tourner, mais le prochain CVE découvert dans ce contrôleur n’aura pas de patch officiel. La distinction est exactement la même que celle entre « le binaire existe » et « quelqu’un le maintient ».

Le calendrier n’a pas laissé de marge. Le 24 mars 2026, le dépôt kubernetes/ingress-nginx est officiellement passé EOL et archivé. Une déclaration conjointe du Steering Committee et du Security Response Committee, le 29 janvier 2026, avait déjà durci le ton en insistant sur les enjeux de sécurité. Le Ingress lui-même, en tant qu’API cœur de Kubernetes, n’est pas supprimé : la retraite ne concerne que le projet kubernetes/ingress-nginx, le contrôleur de référence.

Pourquoi la retraite, plutôt qu’un énième patch

La décision ne vient pas de nulle part : elle vient d’une accumulation de failles structurelles. Le déclencheur s’appelle IngressNightmare — CVE-2025-1974, un CVSS 9,8 découvert par Wiz Research en mars 2025. Une exécution de code non authentifiée passait par le webhook d’admission du contrôleur ; comme ingress-nginx peut lire par défaut tous les Secrets du cluster, la RCE devenait une prise de contrôle du cluster en une seule étape. À l’époque, 43 % des environnements cloud étaient exposés et plus de 6 500 clusters avaient le webhook joignable depuis Internet.

Le 2 février 2026, quatre nouvelles failles HIGH — CVE-2026-1580, CVE-2026-24512, CVE-2026-24513 et CVE-2026-24514 — ont été publiées simultanément, toutes de la même famille : l’injection de configuration NGINX via des annotations ou des chemins. Le problème de fond est architectural. Une décennie de fonctionnalités s’est accumulée sous forme d’annotations qui injectent de la configuration NGINX brute, comme l’annotation configuration-snippet. Chaque nouvelle annotation est donc une primitive d’injection potentielle, et l’API Ingress étant gelée — aucune fonctionnalité nouvelle — la classe de bug ne pouvait pas être corrigée sur place. La retraite est la remédiation.

Ce que Gateway API change réellement

Gateway API n’est pas un simple remplaçant de syntaxe : c’est un changement de modèle de propriété. Là où Ingress empilait trois métiers dans un seul objet — le câblage du load-balancer, les règles de routage et une pile d’annotations propres au contrôleur — Gateway API les sépare par rôle.

Concrètement, trois ressources remplacent l’objet unique. La GatewayClass, possédée par l’équipe plateforme, déclare le contrôleur. La Gateway, également plateforme, matérialise l’infrastructure réconciliée. L’HTTPRoute, possédée par l’équipe applicative, porte les règles de routage. Dans une flotte multi-tenant, c’est la fin du scénario où un développeur casse le TLS de tout le monde avec une annotation mal placée.

Le gain de fond est la portabilité. Une annotation nginx.ingress.kubernetes.io/rewrite-target ne veut rien dire pour un autre contrôleur ; un filtre URLRewrite typé l’est par n’importe quelle implémentation conforme. La version 1.4, publiée en octobre 2025, a promu deux briques devenues indispensables : BackendTLSPolicy en GA pour le TLS entre la passerelle et le backend, et TLSRoute en GA pour le passthrough TLS par SNI. Vingt implémentations conformes ou plus existent déjà.

ingress2gateway 1.0 : la mécanique, pas la magie

L’outil communautaire ingress2gateway a atteint sa version 1.0 le 20 mars 2026, calé sur la fenêtre de migration. Il convertit mécaniquement les objets Ingress en Gateway API, avec une couverture de plus de 30 annotations.

La promesse est réelle, mais bornée. Ce qui se convertit proprement, c’est le cœur : les règles host/path, la réécriture d’URL, les canaris par poids, le TLS par Secret. Ce qui ne se convertit pas, c’est précisément la partie risquée : configuration-snippet, server-snippet, auth-url/auth-signin et les paires de canari exotiques. Ces annotations-là n’ont pas d’équivalent automatique, parce qu’elles injectaient de la configuration brute — exactement la classe de bug qui a tué le projet.

La règle est simple : le résultat d’ingress2gateway est un point de départ à relire, pas un livrable. Une conversion sans revue humaine déplace le risque de l’injection d’annotation vers une route mal typée, sans le supprimer.

La migration en quatre phases, sans flag day

Tous les guides sérieux convergent vers quatre phases, rendues possibles par un fait simple : l’ancien et le nouveau plan de données peuvent servir les mêmes Services en parallèle.

Phase 1 — Inventaire des annotations. Listez chaque objet Ingress et chaque clé d’annotation utilisée. La plupart des flottes découvrent que 80 % de leurs Ingress utilisent les cinq mêmes annotations — émetteur, réécriture, CORS, timeouts de proxy, protocole backend — et que les 20 % restants concentrent tout le risque. Le livrable est un tableur à trois colonnes : annotation, compteur, équivalent Gateway API. Les lignes sans équivalent sont votre vrai plan de projet.

Phase 2 — Conversion mécanique, puis revue. Installez l’outil, convertissez, puis relisez chaque objet transformé.

go install github.com/kubernetes-sigs/ingress2gateway@latest
ingress2gateway print --input-file ingress.yaml

Phase 3 — Double service. Déployez la Gateway et les HTTPRoute à côté de l’Ingress existant, avec un basculement progressif du trafic — typiquement par canari ou par hôte.

Phase 4 — Bascule et purge. Une fois le trafic confirmé sur la nouvelle voie, supprimez l’ancien contrôleur et les annotations qu’il transportait. C’est la seule phase qui supprime du risque au lieu d’en déplacer.

Choisir une implémentation pour une flotte qu’on possède

Une fois la décision de migrer prise, reste le choix du contrôleur, et il dépend de ce qui est déjà en place. La règle de base : si Istio est déployé, utilisez son Gateway — pas de contrôleur supplémentaire à opérer. Pour un projet neuf, Envoy Gateway offre la meilleure conformité et l’extensibilité du plan de données Envoy. Pour une transition à changement minimal depuis ingress-nginx, NGINX Gateway Fabric est l’ajustement le plus naturel, puisque l’équipe conserve l’univers NGINX et une partie de ses réflexes de configuration.

Sur EKS, le contrôleur AWS Load Balancer apporte l’intégration native ALB/NLB et IAM. Traefik reste pertinent pour les flottes de taille petite à moyenne qui veulent l’automatisation Let’s Encrypt déjà intégrée. Le critère qui tranche est rarement la fonctionnalité — toutes ces implémentations couvrent le tronc commun — mais la compétence déjà présente dans l’équipe : on migre vers ce qu’on sait opérer, pas vers ce qui est le plus récent.

Verdict

Ingress-nginx est mort en mars 2026, et la dernière personne ayant encore un nom sur la ligne — Microsoft, via le pont de correctifs critiques d’AKS — rend son tablier en novembre 2026.

Si votre flotte tourne encore derrière ingress-nginx, lancez l’inventaire des annotations cette semaine : le tableur est toujours plus petit que la peur qu’il inspire, et les configuration-snippet toujours plus étranges qu’on ne l’espère. Si vous êtes en environnement réglementé, sachez qu’un logiciel EOL dans le chemin L7 déclenche déjà des findings automatiques en SOC 2, PCI-DSS, ISO 27001 et HIPAA — le délai est devenu un risque d’audit, pas seulement technique. Et si vous démarrez un nouveau cluster, partez directement sur Gateway API : le coût de ne rien migrer est désormais supérieur au coût de la migration.

Références

• Kubernetes Contributors — Ingress NGINX Retirement: What You Need to Know, 12 novembre 2025
• Gateway API — Migrating from Ingress
• bex.co — Your Ingress-Nginx Has an Expiry Date: What Moving to Gateway API Actually Takes, 10 septembre 2026
• DEV Community — Ingress-NGINX Is Officially Retired: Complete Gateway API Migration Guide, mars 2026