Réseau Kubernetes : l’abandon d’Ingress Nginx met ses utilisateurs en danger
Encore largement utilisé bien qu’officiellement obsolète depuis 2023, le logiciel de routage s’arrête ce mois-ci. L’abandonner étant trop long et trop compliqué, nombre d’utilisateurs semblent vouloir le conserver alors que ses failles ne seront plus corrigées.
Ingress Nginx, un sous-projet de Kubernetes très répandu, a vu son support communautaire prendre fin le 13 mars. Cela pose un risque important de vulnérabilité chez tous les utilisateurs de ce module logiciel qui sert à router le trafic réseau externe vers les services déployés sur un cluster Kubernetes. D’autant plus qu’Ingress Nginx est souvent utilisé pour appliquer les politiques de sécurité au trafic entrant.
La situation est alarmante. Un communiqué publié en janvier par la Cloud Native Computing Foundation (CNCF) indiquait que, selon une étude menée par l’entreprise membre Datadog, environ la moitié des déploiements d’applications cloud natives utilisent encore ce module.
« On ne saurait trop insister sur la gravité de la situation ni sur l’importance de commencer immédiatement la migration vers des solutions alternatives. »
Communiqué CNCF
La dernière version d’Ingress Nginx a été publiée le 13 mars, avec des mises à jour visant à prendre en charge la version 1.35 de Kubernetes et à corriger une vulnérabilité critique. Selon la déclaration de janvier, aucune autre vulnérabilité critique ni aucun autre exploit ne sera corrigé par les responsables du projet. Et aucune correction de bug ni mise à jour de fonctionnalités ne sera ajoutée.
« On ne peut pas ignorer ce problème, le balayer d’un revers de main ou attendre la dernière minute pour s’en occuper », indique le communiqué de la CNCF. « On ne saurait trop insister sur la gravité de la situation ni sur l’importance de commencer immédiatement la migration vers des solutions alternatives telles que l’API Gateway de Kubernetes ou l’un des nombreux autres contrôleurs de trafic entrant. »
Ingress Nginx repose sur l’API Ingress d’origine qui avait été conçue au début de Kubernetes et qui a officiellement été remplacée par l’API Gateway en 2023, date de sa publication en version définitive. Cela dit, des projets CNCF comme Istio prenaient en charge l’API Gateway dès 2022.
L’API Ingress gère le routage de base du trafic HTTP au niveau des applications, laissant la gestion plus avancée du trafic à divers contrôleurs d’entrées (dits d’ingress, donc) qui utilisent des extensions dédiées, configurées séparément. L’API Gateway, en revanche, prend en charge davantage de protocoles réseau, tels que TCP, UDP et gRPC, et inclut un ensemble standardisé de définitions pour les capacités des contrôleurs.
Des entreprises prises au dépourvu
Problème, alors que le retrait d’Ingress Nginx a officiellement été annoncé lors de la conférence KubeCon américaine de novembre 2025, un certain nombre d’utilisateurs n’en prennent conscience que maintenant et se retrouvent à devoir remplacer le module en urgence, ce qui est encore plus problématique quand leurs procédures de gestion du changement sont longues.
« L’API Gateway de Kubernetes est une bonne technologie… mais ce n’est pas une nouvelle version de l’API d’Ingress Nginx. Il s’agit d’un modèle de ressources fondamentalement différent, reposant sur des hypothèses différentes quant au fonctionnement du routage », se désole Heinan Cabouly, qui est chef d’équipe DevOps dans une entreprise de dispositifs médicaux et qui se trouve dans cette malheureuse situation.
Il explique que la migration dans un environnement soumis au règlement européen sur les dispositifs médicaux est une procédure qui prend environ neuf mois. Or, il ne s’est écoulé que six mois entre l’annonce par la CNCF de l’abandon d’Ingress Nginx et la publication de sa dernière version.
« Comme nous sommes soumis à une réglementation, nos directives de mise à niveau sont plus lentes. Nous avons donc remarqué cet abandon assez tardivement : lorsque nous sommes passés à Kubernetes 1.35. Et le timing n’était pas adapté à notre situation. »
D’autres experts du secteur ont indiqué que les cas comme celui de M. Cabouly sont minoritaires et que de nombreuses entreprises étaient déjà passées à l’API Gateway ou à un autre projet plus récent bien avant le retrait d’Ingress Nginx.
« Je n’ai pas constaté d’impact immédiat : les systèmes continuent de fonctionner, donc cela ne se traduit pas encore par un problème opérationnel », estime ainsi Varun Raj, responsable des plateformes de cloud privé, au sein d’un cabinet de conseil international. « Ce que cela met vraiment en évidence, c’est le niveau de maturité. Les équipes qui ont mis en place de solides pratiques d’ingénierie des plateformes sont déjà en train de migrer ou de tester des alternatives. D’autres reportent cette migration, car elles ne subissent pas de pression immédiate. »
Ingress Nginx va continuer à fonctionner et c’est un problème
« Remplacer Ingress Nginx par une autre technologie implique que toutes vos API [communiquent] correctement. »
Nigel DouglasResponsable des relations avec les développeurs, Cloudsmith
Mais le fait que les systèmes utilisant encore Ingress Nginx continuent de fonctionner est précisément ce qui inquiète les autres membres de la communauté.
« De nombreuses entreprises ne vont pas s’en détourner, même si le module présente des vulnérabilités connues et qui sont exploitées. Et, ce, pour la même raison qu’elles ne l’ont pas désactivé il y a trois ans : Ingress Nginx fonctionnait il y a trois ans, et il fonctionne toujours aujourd’hui », observe Nigel Douglas, responsable des relations avec les développeurs chez Cloudsmith, une entreprise membre de la CNCF.
« Alors certains utilisateurs vont préférer conserver quelque chose qui fonctionne déjà et c’est un problème extrêmement grave. »
Nigel DouglasResponsable des relations avec les développeurs, Cloudsmith
« Remplacer Ingress Nginx par une autre technologie implique que toutes vos API doivent communiquer correctement. Les CRD [définitions de ressources personnalisées, N.D.R.] doivent être fiables. Alors certains utilisateurs vont préférer conserver quelque chose qui fonctionne déjà et c’est un problème extrêmement grave », ajoute-t-il.
Selon un communiqué de la CNCF datant de novembre 2025, l’architecture d’Ingress Nginx comporte notamment des vulnérabilités liées à l’utilisation d’annotations de configuration appelées « snippets ». Celles-ci pourraient être détournées afin de donner le contrôle d’un environnement à un pirate. Le projet souffrait également depuis des années d’un manque de ressources, ne comptant que sur deux mainteneurs bénévoles pour les correctifs et les corrections de bogues.
Des alternatives, mais un modèle Open source mis à mal
Il existe des solutions de contournement pour les utilisateurs pris au dépourvu. Heinan Cabouly évalue actuellement, dans des clusters Kubernetes de développement et de préproduction, la version commerciale d’Ingress Nginx qu’édite F5 Networks : NGINX Ingress Controller. Il est aussi temporairement passé à AWS Load Balancer Controller pour les clusters Amazon EKS en production.
Parmi les autres alternatives, on peut citer Traefik, HAProxy Ingress, Cilium Gateway, Envoy Gateway et Kong Ingress. L’éditeur de solutions de sécurité Chainguard assure également la maintenance d’un fork Open source sécurisé d’Ingress Nginx, bien qu’il ne prévoie pas d’y ajouter de nouvelles fonctionnalités.
Pour autant, M. Cabouly déplore que son abandon d’Ingress Nginx soit la dernière migration forcée en date d’une longue série de logiciels d’infrastructure Open source. Son entreprise s’appuyait autrefois sur MongoDB, HashiCorp Terraform ou encore MinIO et tous lui ont posé un problème de changement de licence qui l’a incité à les abandonner.
De fait, M. Cabouly s’interroge à présent sur la viabilité de l’Open source en général. Il se demande notamment pourquoi les membres de premier plan de la CNCF – des hébergeurs, des éditeurs de renom – n’étaient pas intervenus pour contribuer davantage à Ingress Nginx lorsque les responsables de sa maintenance avaient demandé de l’aide.
« Le composant réseau par défaut pour la moitié de toutes les installations Kubernetes était maintenu par une ou deux personnes qui travaillaient la nuit et le week-end. Et ça a duré des années comme ça. Pendant ce temps, tous les grands fournisseurs de cloud construisaient des services managés par-dessus Kubernetes, ils les facturaient aux entreprises et ils publiaient des rapports trimestriels dans lesquels ils vantaient les chiffres d’adoption de Kubernetes », constate-t-il, amer.
Interrogé à ce sujet, Chris Aniszczyk, le directeur technique de la CNCF, répond que la fondation n’impose pas de parcours de développement unique à ses projets, qu’elle maintient une séparation claire entre la direction de la fondation et les responsables de projets, et que ni le Conseil d’administration de la CNCF ni le Comité de supervision technique ne gèrent directement les projets hébergés par la CNCF.
« Ce que nous fournissons, c’est un cadre de maturité structuré, allant des stades Sandbox à Graduated [de laboratoire à officiellement promu N.D.R.]. Il sert de feuille de route, sans les frictions d’une gouvernance rigide et uniforme », se défend M. Aniszczyk. « Nous fournissons également des outils d’évaluation de la santé des projets via le site insights.linuxfoundation.org, sur lequel nous publions des données transparentes à propos de la santé des projets. Ces données sont accessibles à tous pour permettre de prendre des décisions éclairées sur la marche à suivre », insiste-t-il
Il n’empêche que M. Cabouly confie que son entreprise et les clients de son cabinet de conseil, HT DevOps, soumettraient désormais les projets Open source à un examen plus minutieux.
« Cela a en fait commencé lorsque nous sommes passés d’HashiCorp Terraform à OpenTofu après que HashiCorp soit passé à une licence commerciale. Nous avons contacté OpenTofu pour leur demander qui étaient leurs bailleurs de fonds, et quel était leur plan d’action. Cela afin de nous assurer que nous n’allions pas changer de plateforme pour nous retrouver à nouveau livrés à nous-mêmes », raconte-t-il.
Cet article est une adaptation d’un article initialement paru en anglais sur SearchITOperations.
