Ingress NGINX : fin de vie en mars 2026, un risque majeur pour la sécurité des clusters Kubernetes

Ingress NGINX se rapproche de sa date de retraite, et les mainteneurs continuent de colmater des failles pendant qu’il est encore temps. Le message derrière les correctifs est limpide: profite des derniers patchs, parce qu’en mars 2026, c’est terminé. Après ça, plus de releases, plus de bugfix, plus de correctifs de sécurité. Et si une nouvelle vulnérabilité sort le lendemain, tu restes avec.

Le truc, c’est que ce contrôleur traîne un historique de soucis de sécurité liés à sa surface d’attaque et à des choix de design – notamment tout ce qui touche aux annotations et aux “snippets” NGINX. On a déjà vu ce que ça donne quand plusieurs failles s’enchaînent: CVSS 9.8, exécution de code à distance, et derrière, risque de prise de contrôle du cluster. Du coup, l’actu du jour n’est pas “super, c’est patché”, c’est “tu as une échéance et un plan de migration à faire”.

Mars 2026: après l’EOL, plus aucun patch

La date à retenir tient en trois mots: mars 2026. Jusque-là, maintenance “best effort”. Après, rideau. Ça veut dire un truc très concret pour toi: si une vulnérabilité est découverte après l’arrêt, elle restera ouverte, point. Ton ingress continuera de router du trafic, tes certificats TLS continueront de se renouveler si tu as bien câblé, mais côté sécurité tu roules sans ceinture. Pour un composant internet-facing, c’est le genre de pari qui finit en incident.

Sur le terrain, ça touche plus de monde qu’on ne le croit. Ingress NGINX est partout: petits clusters de start-up, grosses plateformes multi-régions, environnements hybrides. Et c’est justement ce volume qui fait peur: si beaucoup d’organisations gardent le contrôleur après l’EOL, tu te retrouves avec une cible “standard” dans l’écosystème. Un attaquant n’a pas besoin d’être créatif, il a juste besoin d’un angle réplicable.

J’ai eu ce cas chez un client – une équipe plateforme de 6 personnes – où l’ingress était tellement “dans les tuyaux” qu’ils ne savaient même plus quels pipelines déployaient quoi. Le contrôleur était installé par Helm, sur deux clusters, avec des variantes de valeurs selon les environnements. Résultat: avant même de parler remplacement, il a fallu faire l’inventaire, comprendre les annotations utilisées, et retrouver les dépendances implicites (auth, rate limiting, headers).

Et il y a un deuxième effet kiss cool: la dérive de compatibilité. Kubernetes avance, l’écosystème réseau aussi. Si ton contrôleur ne bouge plus, tu finis avec des frictions sur les versions, des comportements qui changent autour, et une dette opérationnelle qui grossit. Tu peux “geler” ton cluster, bien sûr – mais geler la prod sur plusieurs années, c’est rarement réaliste quand tu as des exigences de sécurité, de conformité, ou juste des besoins applicatifs.

IngressNightmare: la chaîne de cinq CVE qui a marqué 2025

Si tu veux comprendre pourquoi tout le monde est nerveux, il faut revenir à l’épisode qui a laissé des traces: IngressNightmare, publié par Wiz Research en mars 2025. Ce n’était pas “une faille”, c’était une chaîne de cinq vulnérabilités combinables. Individuellement, on est sur du medium à high. Enchaînées, tu montes sur du critique, avec un score CVSS 9.8. Le scénario qui fait mal: exécution de code à distance sur le pod du contrôleur, puis escalade vers une prise de contrôle du cluster.

Dans le détail, une partie de la tempête venait de failles d’injection via annotations. Trois CVE ont été mises en avant dans ce lot: CVE-2025-24514 (injection via auth-url), CVE-2025-1097 (injection via auth-tls-match-cn), CVE-2025-1098 (injection via mirror-target et mirror-host). Ce genre de vecteur est vicieux parce qu’il ressemble à de la config “normale” dans des manifests. Et si tu as des chaînes CI/CD qui appliquent des Ingress sans garde-fous, tu te crées une autoroute.

Le plus frustrant, c’est la séquence “patch qui ne règle pas le fond”. À une époque, une réponse a consisté à bloquer des mots-clés dangereux et à introduire un flag du style allow-snippet-annotations=false. Sauf que par défaut, le flag restait à true pour éviter de casser des clusters existants. Et beaucoup d’équipes dépendaient des snippets. Résultat: contournements, nouveaux bypass, et un cycle où on traite les symptômes, pas la cause structurelle.

Je te la fais simple: quand ton ingress te permet d’injecter des bouts de configuration puissants, tu gagnes en flexibilité… mais tu invites aussi des problèmes de sécurité. Et même si ton équipe est carrée, tu n’es pas seul: tu as des dizaines d’équipes applicatives, des prestas, des outils GitOps, des charts Helm tiers. Il suffit d’un mauvais usage, d’un contrôle d’accès trop large, ou d’un review raté, et tu te retrouves à expliquer à la direction pourquoi “une annotation” a ouvert une brèche.

Les “snippets” NGINX: pratique, mais toxique en prod

Les snippets, c’est l’outil qui rend Ingress NGINX super populaire dans les boîtes pressées: tu peux coller une directive NGINX à la volée, faire un rewrite exotique, ajouter des headers, bricoler un comportement sans attendre une feature officielle. Sauf que cette flexibilité est devenue, avec le temps, une dette technique énorme. Des mainteneurs et observateurs du projet parlent carrément de dette “insurmontable” et de surface d’attaque qui ne cesse de s’élargir.

Concrètement, dans une plateforme Kubernetes, tu vois souvent des annotations du type configuration-snippet ou server-snippet utilisées comme des rustines. Exemple classique: un service legacy qui exige un header spécifique, ou un contournement CORS “vite fait”. Le jour où tu veux migrer, tu te rends compte que la moitié de tes règles de routage ne sont pas dans un modèle standard, mais dans des bouts de config dispersés. Et côté sécurité, tu as des mécanismes puissants exposés via des ressources que beaucoup d’équipes peuvent modifier.

Il y a aussi l’aspect gouvernance. Dans une org un peu mature, tu veux des garde-fous: qui a le droit de toucher au trafic entrant, qui peut faire du TLS termination, qui peut activer des options d’auth, qui peut injecter des directives. Avec les annotations et les snippets, tu finis vite avec une “annotation sprawl” – une jungle – où il n’y a plus de lisibilité. Et quand arrive une CVE critique, tu dois répondre en urgence à une question simple: “qui utilise quoi?” Souvent, tu ne sais pas.

Nuance importante: ce n’est pas un procès contre NGINX en tant que serveur. NGINX est solide, connu, et largement utilisé. Le problème, c’est l’assemblage “contrôleur communautaire + modèle Ingress + annotations très permissives”, maintenu pendant des années par une équipe minuscule. Quand tu fais porter une brique stratégique à 1 ou 2 personnes qui bossent le soir et le week-end, tu peux admirer l’effort – mais tu ne peux pas baser ta prod là-dessus indéfiniment.

Pourquoi le monde Kubernetes pousse la Gateway API

Si Ingress NGINX part à la retraite, ce n’est pas juste à cause des CVE. Il y a une direction plus large côté Kubernetes: la Gateway API. L’idée, c’est de sortir du modèle Ingress devenu trop limité et trop “hacké” via annotations, pour aller vers quelque chose de plus moderne et extensible. Gateway API met mieux en avant des concepts comme le multi-tenant, des politiques standardisées, et une gestion plus propre du routage L4/L7.

Dans la pratique, ça veut dire que tu peux gérer HTTP, gRPC, TCP, UDP dans un cadre plus cohérent. Et surtout, tu réduis le besoin de coller des annotations obscures partout. C’est aussi un langage plus commun entre contrôleurs: cloud providers, solutions Envoy, gateways orientées service mesh. Quand tu changes d’implémentation, tu as moins l’impression de réécrire ton infra “à la main”. C’est exactement ce que recherchent les équipes plateforme: de la portabilité et moins de plomberie.

On voit déjà la fragmentation des technos de routage: NGINX OSS, NGINX Plus, Envoy et ses dérivés (Kong, Ambassador, Gloo, Istio), contrôleurs gérés côté AWS/GCP/Azure. Et c’est là que le contrôleur communautaire ingress-nginx perd son statut de fondation stratégique. Le marché ne manque pas d’options, le standard évolue, et l’investissement se déplace. Garder l’ancien modèle juste parce que “ça marche”, c’est une tentation – mais tu payes après.

Le point qui pique, c’est l’effort humain. Les sources parlent d'”operational fatigue” pour les équipes DevOps et plateforme, et je confirme: quand tu passes ton temps à maintenir des règles de routage, des annotations, des exceptions, tu ne fais plus de produit. La promesse de la Gateway API, c’est de remettre de l’ordre, de rendre les politiques plus propres, et de réduire le bricolage. Ça ne supprime pas le boulot, mais ça le rend moins ingrat.

Plan de migration: audit, double run, rollback

Si tu veux éviter le mur de mars 2026, le plan est connu et plutôt pragmatique. Première étape: audit. Tu dois identifier où ingress-nginx tourne, dans quels namespaces, et comment il est déployé. Une commande du style kubectl get pods –all-namespaces avec le bon selector te donne déjà une cartographie. Ensuite, tu listes tes ressources Ingress, tes annotations, tes ConfigMaps, et tu repères les usages sensibles comme les snippets. Sans cet inventaire, tu pilotes à l’aveugle.

Deuxième étape: choisir un remplaçant. Les recommandations qui reviennent: aller vers des contrôleurs basés sur la Gateway API (souvent fournis par les cloud providers), ou des gateways basées sur Envoy, ou une voie commerciale type NGINX Plus si tu veux du support et des features avancées. Il n’y a pas de réponse universelle: si tu es sur du multi-cloud, tu vas privilégier la portabilité; si tu es à fond sur un cloud, un contrôleur managé peut te simplifier la vie.

Troisième étape: le “side-by-side”. Tu fais tourner l’ancien et le nouveau en parallèle, tu routes du trafic de test, tu compares. Tu vérifies le routage, le TLS, le rate limiting, CORS, l’auth, tout ce que tu utilises vraiment – pas ce qui est dans la doc. Et tu testes la perf. Une migration d’ingress, ce n’est pas un refactor de code: c’est un changement de point d’entrée. La moindre différence de comportement sur les headers, les timeouts, ou les redirects peut te casser une appli.

Dernier point, et c’est celui que les équipes oublient quand elles sont pressées: le rollback. Il te faut une procédure de repli prête, testée, avec des garde-fous. L’approche recommandée, c’est de commencer par des applis non critiques, valider, puis élargir progressivement vers les workloads critiques. Et tu gardes un “escape hatch” jusqu’au bout. J’ai vu des migrations réussies parce qu’elles étaient ennuyeuses, graduelles, et obsédées par les métriques. Les migrations ratées, c’est souvent du “big bang” un vendredi soir.