ingress-nginx prend sa retraite en mars 2026 : passez à Gateway API avant qu’il ne soit trop tard

11 novembre 2025, le projet Kubernetes annonce la retraite d’ingress-nginx. 24 mars 2026, le dépôt GitHub est archivé en lecture seule — plus aucune release, plus aucun correctif, plus aucune rustine de sécurité. 9,8 sur l’échelle CVSS : c’est le score de la CVE-2025-1974 (surnommée IngressNightmare), qui a exposé au grand jour la fragilité architecturale du contrôleur le plus déployé de l’écosystème Kubernetes. La migration vers Gateway API n’est plus un chantier « un jour » : c’est une décision qui engage la sécurité de vos clusters, et le compte à rebours a déjà sonné.

Pourquoi ingress-nginx s’arrête

ingress-nginx n’est pas un projet mineur. Déployé dans plus de 40 % des clusters Kubernetes, il a servi de contrôleur de référence pendant une décennie, indépendant de tout fournisseur cloud, flexible jusqu’à l’excès. Mais cette flexibilité a fini par le tuer.

Le problème central est structurel. ingress-nginx traduit des objets Ingress en configuration nginx via un modèle où les utilisateurs peuvent injecter des directives arbitraires à travers des annotations — notamment l’annotation nginx.ingress.kubernetes.io/server-snippet. Ce mécanisme, conçu comme une soupape de confort, est devenu une surface d’attaque impossible à colmater. Le rapport de sécurité de novembre 2024 le dit sans détour : « ce qui était hier une option utile est aujourd’hui une dette technique insurmontable ».

À cela s’ajoute un problème de gouvernance. Malgré ses 19 500 étoiles GitHub et ses 8 600 forks, le projet n’a jamais eu plus d’un ou deux mainteneurs actifs, bénévoles, travaillant le soir et le week-end. La tentative de bâtir un successeur — le projet InGate — n’a jamais dépassé le stade expérimental et a été abandonnée. Le SIG Network et le Security Response Committee de Kubernetes ont conclu que maintenir le statu quo revenait à laisser une bombe à retardement dans les clusters.

Le dépôt est archivé. Les artefacts existants — images de conteneurs, charts Helm — restent accessibles, mais ne recevront aucune mise à jour de sécurité. Un cluster qui tourne encore sous ingress-nginx après mars 2026 est un cluster qui absorbera chaque future CVE sans aucun recours.

CVE-2025-1974 : le réveil brutal

Le 24 mars 2025, les mainteneurs d’ingress-nginx publient un correctif pour cinq vulnérabilités. La plus grave, CVE-2025-1974, obtient un score CVSS de 9,8 — le niveau le plus élevé avant la note maximale. Surnommée IngressNightmare par l’équipe de recherche de Wiz qui l’a découverte, cette faille permet à n’importe quel processus présent sur le réseau de pods de prendre le contrôle complet du cluster.

Le vecteur d’attaque est redoutablement simple. Le Validating Admission Controller d’ingress-nginx écoute sur le réseau interne du cluster et accepte des requêtes sans authentification. En exploitant les vulnérabilités d’injection de configuration — rendues possibles par les fameuses annotations snippet — un attaquant présent sur le réseau de pods pouvait :

• lire tous les Secrets accessibles au contrôleur (par défaut : tous les Secrets du cluster) ;
• exécuter du code arbitraire dans le contexte du contrôleur ;
• rebondir vers le plan de contrôle avec les privilèges du ServiceAccount d’ingress-nginx.

Aucun accès administrateur requis. Aucune permission de créer un objet Ingress. La seule condition : être présent sur le réseau de pods, ce qui est le cas de toute charge de travail compromise dans le cluster, et souvent de l’ensemble du VPC cloud ou du réseau d’entreprise.

Les chercheurs de Wiz — Nir Ohfeld, Sagi Tzadik, Ronen Shustin et Hillai Ben-Sasson — ont démontré que cette chaîne d’exploitation fonctionnait sur une instance ingress-nginx par défaut. Les correctifs (v1.11.5 et v1.12.1) ont comblé les brèches, mais la leçon architecturale reste : un modèle qui accepte des directives de configuration arbitraires depuis des objets Kubernetes non privilégiés est structurellement vulnérable. Gateway API ne reproduit pas cette erreur.

Gateway API : le successeur est prêt

Gateway API n’est pas une nouveauté : le projet a débuté en 2019, a atteint le statut GA (Generally Available) en octobre 2023 avec la version v1.0, et est aujourd’hui intégré au canal standard de Kubernetes depuis la version 1.31. En janvier 2026, la spécification en est à sa version v1.2, et 14 implémentations conformes sont disponibles — dont Cilium, Istio, Envoy Gateway, Traefik, NGINX Gateway Fabric, HAProxy Ingress et Gloo Gateway.

La différence fondamentale avec Ingress est architecturale. Là où Ingress définissait un objet unique avec des annotations par contrôleur, Gateway API découpe le problème en trois niveaux de responsabilité :

• Infrastructure Provider déclare une GatewayClass : « voici quel contrôleur gère cette classe de passerelle ».
• Cluster Operator déploie une Gateway : « voici une instance d’infrastructure qui écoute sur tel port, avec tel protocole ».
• Application Developer définit des Routes (HTTPRoute, GRPCRoute, TCPRoute, TLSRoute) : « voici comment router le trafic de tel domaine vers tel service ».

Cette hiérarchie de rôles a une conséquence directe sur la sécurité : un développeur qui crée une HTTPRoute n’a pas besoin de droits sur la Gateway ni sur la GatewayClass. Il ne peut pas injecter de configuration arbitraire dans le plan de données. La surface d’attaque est réduite à la surface d’API prévue, sans échappatoire par annotation.

Autre avantage concret : Gateway API est nativement multi-protocole. Une même Gateway peut router du HTTP, du gRPC et du TCP sans bidouillage — là où Ingress était limité au HTTP/HTTPS et imposait des contournements (ConfigMaps TCP/UDP) pour le reste.

Le chemin de migration en trois étapes

Migrer d’ingress-nginx à Gateway API ne se fait pas en une commande magique, mais le chemin est balisé.

1. Installer un contrôleur Gateway API

Première décision : quel contrôleur utiliser ? La réponse dépend de votre existant.

• Vous êtes en cloud : privilégiez le contrôleur natif de votre fournisseur — AWS Load Balancer Controller, GKE Gateway Controller, Azure Application Gateway for Containers. Ils provisionnent automatiquement les load balancers cloud.
• Vous êtes en bare-metal ou on-premise : les implémentations logicielles dominantes sont Envoy Gateway (léger, soutenu par le projet Envoy), Cilium (si vous l’utilisez déjà comme CNI) et Traefik (configuration simple, dashboard intégré).
• Vous voulez rester en territoire NGINX : NGINX Gateway Fabric est le successeur officiel, développé par la même équipe F5/NGINX qui contribuait à ingress-nginx.

L’installation se fait généralement via Helm :

# Exemple avec Envoy Gateway
helm install eg oci://docker.io/envoyproxy/gateway-helm \
  --version v1.3.0 -n envoy-gateway-system --create-namespace

2. Créer GatewayClass et Gateway

Une fois le contrôleur installé, déclarez la GatewayClass puis une Gateway qui écoutera le trafic entrant :

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: eg
spec:
  controllerName: gateway.envoyproxy.io/gatewayclass-controller
---
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: external-gateway
spec:
  gatewayClassName: eg
  listeners:
    - name: http
      protocol: HTTP
      port: 80
      allowedRoutes:
        namespaces:
          from: All

À ce stade, la passerelle obtient une adresse IP (externe ou interne selon l’implémentation). C’est l’équivalent du Service de type LoadBalancer qu’ingress-nginx créait automatiquement.

3. Migrer les Ingress vers des HTTPRoutes

C’est l’étape la plus manuelle. Chaque objet Ingress doit être converti en HTTPRoute. Voici un exemple de conversion pour un cas classique :

# Avant : Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api-service
                port:
                  number: 8080

# Après : HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: app-route
spec:
  parentRefs:
    - name: external-gateway
  hostnames:
    - app.example.com
  rules:
    - matches:
        - path:
            type: PathPrefix
            value: /api
      backendRefs:
        - name: api-service
          port: 8080

Deux différences notables. D’abord, la HTTPRoute référence explicitement la Gateway parente via parentRefs — le routage est déclaré côté application, pas côté infrastructure. Ensuite, il n’y a pas d’annotations : toute la configuration de routage (matchs d’en-têtes, poids de trafic, redirections, filtres de modification de requêtes) est exprimée dans le schéma natif de l’API.

Pour les annotations avancées — rate limiting, authentification, CORS — Gateway API propose des filtres d’extension (HTTPRouteFilter) et des politiques (BackendTLSPolicy, futures ServicePolicy) plutôt que des annotations magiques.

Quels risques si vous ne migrez pas

Attendre, c’est accepter trois risques cumulatifs :

• Zéro correctif de sécurité. La prochaine vulnérabilité dans nginx ou dans le code d’ingress-nginx sera publiée sans rustine. Votre cluster restera exposé, sans recours possible à part la migration d’urgence en catastrophe — le pire scénario pour une équipe ops.
• Incompatibilité Kubernetes future. Bien que l’API Ingress elle-même soit gelée et ne sera pas retirée de Kubernetes, le contrôleur ingress-nginx teste sa compatibilité contre des versions spécifiques. La dernière version compatible est Kubernetes 1.32. Les versions ultérieures fonctionneront peut-être, mais aucune garantie n’est donnée.
• Perte de compétence collective. Plus le temps passe, plus les équipes qui maîtrisent ingress-nginx se raréfient, et plus les équipes qui maîtrisent Gateway API deviennent la norme. Rester sur un contrôleur mort, c’est s’isoler du marché du travail et de la communauté.

Le risque n’est pas théorique. La CVE-2025-1974 a prouvé qu’une vulnérabilité critique peut surgir sans préavis. La seule différence en mars 2026, c’est qu’il n’y aura personne pour publier le correctif.

Verdict

Si vos clusters tournent encore sous ingress-nginx, vous avez trois mois pour migrer. Voici comment prioriser :

• Clusters exposés sur Internet : migration prioritaire. Commencez par les environnements de production, service par service. Chaque Ingress migré est une surface d’attaque en moins.
• Clusters internes avec réseau de pods restreint : migration programmée avant mars 2026. Le risque est moindre à court terme, mais l’absence de correctifs futurs reste un danger existentiel.
• Nouveaux clusters : ne déployez plus jamais ingress-nginx. Partez directement sur le contrôleur Gateway API de votre choix. La courbe d’apprentissage est réelle, mais elle est rentabilisée dès la première HTTPRoute.

La migration vers Gateway API n’est pas un luxe ni un saut dans l’inconnu. C’est une technologie stable, soutenue par tout l’écosystème, et surtout la seule qui recevra des correctifs de sécurité dans six mois. ingress-nginx a bien servi la communauté pendant une décennie, mais son heure est passée.

Références

• Kubernetes Blog — Ingress NGINX Retirement: What You Need to Know (11 novembre 2025)
• Kubernetes Blog — CVE-2025-1974: What You Need to Know (24 mars 2025)
• Dépôt GitHub ingress-nginx (archivé) — archivé le 24 mars 2026
• Gateway API — Documentation officielle
• Gateway API — Implémentations conformes
• Kubernetes Documentation — Gateway API
• Wiz Research — IngressNightmare (CVE-2025-1974)
• GitHub Issue — ingress-nginx maintenance future