El ocaso de Ingress-NGINX: riesgos estructurales y la consolidación de Gateway API en Kubernetes

Durante casi una década, Ingress-NGINX ha sido el estándar de facto para exponer servicios HTTP/HTTPS en Kubernetes. Su adopción masiva lo convirtió en una pieza crítica dentro de la infraestructura cloud-native, presente tanto en entornos empresariales como en plataformas de alto impacto.

Sin embargo, este escenario ha cambiado de forma definitiva. Desde marzo de 2026, el proyecto está oficialmente retirado, y tanto Kubernetes como sus mantenedores han confirmado que no habrá más actualizaciones, ni siquiera de seguridad. Este punto marca un antes y un después: no se trata simplemente de la evolución natural de una tecnología, sino de una ruptura estratégica con implicaciones directas en la seguridad de miles de clusters en producción.

Un problema estructural: cuando el diseño compromete la seguridad

La retirada de Ingress-NGINX no puede entenderse únicamente como una cuestión de mantenimiento. Llega precedida por una sucesión de vulnerabilidades críticas que han puesto de manifiesto problemas de diseño profundos. A lo largo de 2025 y 2026 se ha consolidado un patrón especialmente preocupante: inyección de configuración → ejecución remota de código → compromiso total del cluster.

Uno de los casos más representativos fue el conocido como IngressNightmare (CVE-2025-1974), una vulnerabilidad que permitía la ejecución remota de código sin autenticación desde la red interna del cluster. El impacto potencial era máximo: acceso a todos los secretos gestionados por Kubernetes y capacidad de toma de control completa del entorno.

Lejos de ser un incidente aislado, este fallo evidenció una tendencia que se repetiría en múltiples CVEs posteriores. Vulnerabilidades como CVE-2025-1097 (auth-tls-match-cn), CVE-2025-15566 (auth-proxy-set-headers), CVE-2026-1580 (auth-method), CVE-2026-3288 (rewrite-target) o incluso CVE-2026-24512, que afecta directamente al campo path, comparten un mismo origen: la manipulación de entradas no validadas que terminan alterando la configuración interna del proxy.

En todos estos casos, el vector de ataque se apoya en un elemento común dentro del modelo de Ingress: el uso de annotations y campos interpretables como configuración dinámica. Este enfoque, basado en entradas no tipadas ni validadas estrictamente, ha demostrado ser especialmente propenso a ataques de inyección.

Pero el problema va más allá de una mala práctica puntual. Se trata de un fallo conceptual. En la mayoría de despliegues reales, el controlador de Ingress opera con acceso amplio —y en muchos casos global— a los recursos del cluster, incluyendo todos los Secrets. A esto se suma su exposición a tráfico interno y su capacidad para procesar inputs definidos por usuarios a través de objetos Ingress.

El resultado es claro: un fallo aparentemente trivial puede escalar rápidamente hasta convertirse en un compromiso total del cluster. En este contexto, la retirada del soporte introduce un factor adicional de riesgo. La aparición de nuevas vulnerabilidades —incluyendo posibles zero-day— no va a ir acompañada de parches oficiales, transformando a Ingress-NGINX en un componente legado con riesgo acumulativo.

Gateway API: un rediseño necesario

Frente a estas limitaciones, Kubernetes ha impulsado el desarrollo de Kubernetes Gateway API como una alternativa que no solo sustituye a Ingress, sino que redefine completamente su modelo.

Gateway API introduce una separación clara entre los distintos actores que intervienen en la exposición de servicios. La infraestructura, los puntos de entrada y las reglas de enrutamiento dejan de estar concentrados en un único recurso, pasando a distribuirse en objetos independientes con responsabilidades bien definidas.

Este cambio tiene implicaciones directas en seguridad. La eliminación del modelo basado en annotations reduce de forma significativa los vectores de ataque asociados a inyecciones de configuración. Al mismo tiempo, el uso de recursos declarativos y tipados permite validar configuraciones de forma más estricta y predecible. Además, la separación de responsabilidades introduce la posibilidad de controlar explícitamente qué servicios pueden exponerse y quién puede hacerlo, lo que introduce un nivel de gobernanza que era difícil de alcanzar con Ingress. Esto resulta especialmente relevante en entornos multi-tenant o en organizaciones con múltiples equipos operando sobre el mismo cluster.

De la flexibilidad implícita al control explícito

Uno de los cambios más relevantes que introduce Gateway API es el paso de un modelo implícito a uno explícito. Donde antes las configuraciones dependían de convenciones, annotations o comportamientos específicos de cada controlador, ahora se definen mediante estructuras claras y auditables.

Este enfoque no solo mejora la seguridad, sino también la operabilidad. La visibilidad sobre cómo se enruta el tráfico, qué políticas se aplican y qué servicios están expuestos es significativamente mayor. A su vez, facilita la integración con arquitecturas modernas basadas en Zero Trust, donde la identidad y la validación continua del tráfico son elementos clave.

Migración: de Ingress a Gateway API (taller)

A continuación se muestra un caso típico de producción con varias funcionalidades habituales: host, path, reescritura de URL y TLS.

Escenario inicial: Ingress en producción

Este es un ejemplo representativo que podríamos encontrar en cualquier cluster:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
  namespace: default
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  ingressClassName: nginx
  tls:
  - hosts:
    - app.araintel.com
    secretName: tls-cert
  rules:
  - host: app.araintel.com
    http:
      paths:
      - path: /app
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

Paso 1: Crear GatewayClass

Esto dependerá del controller utilizado pero, asumiendo que se utilizará el de NGINX:

apiVersion: gateway.networking.k8s.io/v1
kind: GatewayClass
metadata:
  name: nginx
spec:
  controllerName: k8s.io/ingress-nginx

Paso 2: Definir el Gateway (entrypoint)

Partiendo de una configuración tradicional de Ingress, el primer paso consiste en definir un recurso Gateway que actúe como punto de entrada al sistema. Este recurso establece los puertos y protocolos de exposición, reemplazando el rol que anteriormente desempeñaba el controlador de Ingress.

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
  namespace: default
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80  
  - name: https
    protocol: HTTPS
    port: 443
    tls:
      certificateRefs:
      - name: tls-cert

Con esto ya se define explícitamente TLS, sin el uso de annotations.

Paso 3: Traducir reglas a HTTPRoute

Las reglas de enrutamiento se trasladan posteriormente a recursos HTTPRoute, donde se especifican los dominios, rutas y servicios de destino. Este proceso implica también la eliminación de annotations, cuyas funcionalidades deben reimplementarse mediante filtros explícitos dentro de la nueva API.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: default
spec:
  parentRefs:
  - name: web-gateway
  hostnames:
  - "app.araintel.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /app
    backendRefs:
    - name: web-service
      port: 80

Paso 4: Reemplazar annotations (rewrite, redirect, etc.)

En Ingress teníamos esto bajo el campo metadata.anotations:

nginx.ingress.kubernetes.io/rewrite-target: /

En Gateway API se hace explícito con filtros:

rules:
- matches:
  - path:
      type: PathPrefix
      value: /app
  filters:
  - type: URLRewrite
    urlRewrite:
      path:
        type: ReplacePrefixMatch
        replacePrefixMatch: /
  backendRefs:
  - name: web-service
    port: 80

Paso 5: Forzar HTTPS (equivalente a ssl-redirect)

En Ingress se utilizaba una anotación específica:

nginx.ingress.kubernetes.io/ssl-redirect: "true"

En Gateway API se hace mediante configuración nativa:

listeners:
- name: http
  protocol: HTTP
  port: 80
  allowedRoutes:
    namespaces:
      from: Same
  filters:
  - type: RequestRedirect
    requestRedirect:
      scheme: https
      statusCode: 301

Paso 6: Control de seguridad

Limitar qué namespaces pueden usar el Gateway evita exposición accidental de servicios:

- name: https
  protocol: HTTPS
  port: 443
  tls:
    mode: Terminate
    certificateRefs:
    - name: tls-cert  allowedRoutes:
    namespaces:
      from: Same

Resultado final

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: web-gateway
  namespace: default
spec:
  gatewayClassName: nginx
  listeners:
  - name: http
    protocol: HTTP
    port: 80
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: web-route
  namespace: default
spec:
  parentRefs:
  - name: web-gateway
  hostnames:
  - "app.araintel.com"
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /
    backendRefs:
    - name: web-service
      port: 80

Estrategia de migración

Desde el punto de vista operativo, la transición suele completarse redirigiendo el tráfico de forma gradual hacia el nuevo Gateway, apoyándose en mecanismos como DNS o balanceadores de carga. Durante este proceso, la monitorización continua resulta esencial para garantizar la estabilidad del sistema y detectar posibles desviaciones. Es decir, debemos seguir el siguiente proceso:

1. Desplegar Gateway API en paralelo
2. Mantener Ingress activo
3. Apuntar DNS al nuevo Gateway
4. Monitorizar que el tráfico va hacia el nuevo Gateway
5. Eliminar Ingress progresivamente una vez el tráfico vaya hacia el Gateway y no hacia el Ingress

Conclusión

La retirada de Ingress-NGINX no es un hecho aislado, sino la consecuencia de una serie de limitaciones que han quedado expuestas con el tiempo, especialmente en el ámbito de la seguridad. La acumulación de vulnerabilidades críticas, unida a un modelo de configuración flexible pero difícil de controlar, ha evidenciado la necesidad de un cambio de paradigma.

Gateway API representa ese cambio. No solo introduce mejoras técnicas, sino que establece una base más sólida para construir infraestructuras seguras, gobernables y alineadas con los principios actuales de diseño cloud-native.

En un contexto donde los riesgos ya no son teóricos, sino operativos, la transición deja de ser una opción estratégica para convertirse en una necesidad técnica y de seguridad.