La «puerta» de Kubernetes se cierra para siempre: la comunidad desactiva Ingress NGINX y deja a miles de servicios sin actualizaciones

La comunidad de Kubernetes tomó la decisión de cerrar definitivamente uno de los proyectos más destacados del ecosistema — Ingress NGINX. El trabajo sobre él se reducirá gradualmente y para marzo de 2026 el proyecto se retirará oficialmente. Esto significa que el popular controlador dejará de recibir actualizaciones y los usuarios tendrán que buscar un reemplazo o desarrollar sus propios mecanismos de protección.

Ingress NGINX fue durante largo tiempo considerado una forma cómoda y versátil de exponer acceso HTTP y HTTPS a los servicios dentro de un clúster. El controlador permitía gestionar de manera flexible rutas, reglas y políticas de tráfico; se instalaba tanto en clústeres en la nube como en despliegues locales. Su popularidad se debía a que la herramienta se podía ejecutar con igual facilidad en cualquier infraestructura y abarcaba un amplio conjunto de escenarios.

Pero esa amplitud de funcionalidades con el tiempo se convirtió en un problema insalvable. En la comunidad de Kubernetes hace varios años que se observa que la arquitectura de Ingress NGINX está obsoleta. El soporte de numerosas opciones añadidas en distintos momentos provocó la acumulación de deuda técnica, y el cambio en los enfoques de seguridad convirtió muchas soluciones anteriores en riesgosas. En otras palabras, características que en su día ayudaban a los usuarios ahora se perciben como vulnerabilidades.

Ante esas dificultades, la atención de la comunidad se desplazó hacia alternativas, incluido el proyecto InGate — un intento de crear un controlador de nueva generación compatible no solo con el mecanismo ingress sino también con el Gateway API. Sin embargo, esa iniciativa avanzó lentamente. El mantenimiento de Ingress NGINX dependía en la práctica de 1–2 personas que trabajaban en el desarrollo en su tiempo libre, por las noches y los fines de semana. Para un proyecto que usan miles de clústeres en todo el mundo, ese nivel de recursos resultó insostenible.

La situación se volvió grave tras una serie de investigaciones. Antes de marzo de 2025 ya se habían encontrado fallos críticos en el controlador y se habían corregido dentro de lo posible. Pero la publicación del informe de la compañía Wiz sobre nuevas vulnerabilidades peligrosas que permiten a un atacante tomar el control completo de un clúster de Kubernetes fue el punto final. Los expertos detectaron alrededor de 6000 instalaciones activas de Ingress NGINX — y son ellas las primeras en quedar en riesgo: ya no habrá actualizaciones y las debilidades detectadas permanecerán tal cual.

El miércoles, el comité Kubernetes Security Response tomó la decisión final de detener el proyecto. Las razones se expresaron con claridad: una funcionalidad desmesurada, la deuda técnica acumulada, los cambiantes requisitos de seguridad y el déficit crónico de desarrolladores encargados del mantenimiento no dejan posibilidad de una continuidad plena.

Para los administradores de clústeres esto significa muy poco tiempo para reflexionar. Para marzo de 2026 todas las instalaciones en funcionamiento se convertirán en «software abandonado», que seguirá funcionando pero dejará de recibir correcciones. Los propietarios de la infraestructura tendrán que o bien mitigar temporalmente los riesgos por su cuenta — a través de filtros adicionales, políticas de red y servicios de protección — o planear la migración a otro controlador, teniendo en cuenta las particularidades de sus aplicaciones.

Una cosa está clara: la era de Ingress NGINX en Kubernetes llega a su fin, y el ecosistema afronta la transición hacia mecanismos de trabajo con el tráfico externo más estrictos, previsibles y seguros.