Se tambalea gran parte de Internet: el controlador Ingress de NGINX deja de recibir soporte por el agotamiento de sus desarrolladores

KubeCon en Atlanta reunió muchos anuncios sonoros sobre Kubernetes, pero una de las noticias más importantes pasó casi desapercibida. Uno de los componentes más antiguos y más usados — controlador Ingress NGINX — ha sido declarado oficialmente obsoleto. El proyecto dejará de existir en marzo de 2026. Después de esa fecha no habrá nuevas versiones, ni parches, ni correcciones relacionadas con la seguridad.

Ingress NGINX es un controlador de tráfico entrante para clústeres de Kubernetes. Desempeña el papel de proxy inverso: redirige las solicitudes HTTP y HTTPS externas a los servicios internos correspondientes según las reglas establecidas, incluidas las relativas a dominios, rutas y la configuración TLS. Su función era garantizar un enrutamiento fiable y una distribución uniforme de la carga. En la práctica, por él pasaba todo el tráfico entrante, y la estabilidad de muchas aplicaciones dependía de su correcta configuración. Por eso su popularidad siguió siendo alta: se usaba en todas partes, especialmente en entornos de producción donde se requería previsibilidad y control.

A pesar de su papel clave en el ecosistema Kubernetes, el proyecto durante mucho tiempo dependió literalmente del entusiasmo de un par de personas. Uno o dos desarrolladores mantenían y desarrollaban el proyecto en su tiempo libre. Eso duró años: días laborables, tardes, fines de semana; todo se destinaba a parches, mejoras y a cerrar fallos. El año pasado anunciaron su intención de retirar el proyecto y, al mismo tiempo, empezar a desarrollar un nuevo controlador junto con la comunidad de Gateway API. Sin embargo, ni ese plan transparente y anunciado con antelación logró animar a otros miembros de la comunidad a implicarse: ni en el mantenimiento de Ingress NGINX ni en el desarrollo del sustituto propuesto llamado InGate nadie se involucró de forma notable.

La situación se agravó después de que la empresa Wix descubriera una vulnerabilidad crítica en el proyecto. Según su informe, el exploit permitía a un atacante no solo interferir en el funcionamiento del clúster, sino ejecutar código arbitrario y obtener acceso a todos los datos confidenciales, incluidos secretos de diferentes espacios de nombres. Eso suponía la compromisión total de la plataforma sobre la que se apoyaban las aplicaciones. Tras esas conclusiones, dejar el componente sin soporte activo se volvió imposible incluso teóricamente.

La decisión de retirar el ciclo de vida de Ingress NGINX provocó una reacción fuerte entre algunos usuarios. Algunos expresaron indignación porque el plazo para cerrar el proyecto les pareció insuficiente para reescribir la documentación y migrar a soluciones alternativas. Por supuesto, en grandes empresas y en infraestructuras complejas esas migraciones requieren meses de trabajo. Pero en respuesta, uno de los desarrolladores clave de Kubernetes, Tim Hockin, recordó que los desarrolladores de Ingress NGINX no son empleados contratados, sino voluntarios que trabajaron gratis durante años. Señaló que, en los dos años desde el anuncio sobre la posible retirada, casi nadie ofreció asumir su mantenimiento, y en esa situación el cierre se vuelve inevitable.

El problema, sin embargo, no se reduce a un componente inseguro. Las vulnerabilidades surgen con regularidad; eso no sorprende ni a los ingenieros más templados. La raíz está en el modelo por el que el mundo empresarial interactúa con el software de código abierto. La gran mayoría de las empresas utiliza estas herramientas, pero casi nadie participa en su desarrollo.

William Morgan, al frente de la empresa Buoyant, formuló dos caminos realistas: o el proyecto lo mantiene una compañía que gana directamente con su venta, como hace Buoyant, o lo patrocina una corporación para la que su existencia es crítica, como Google financia Kubernetes para impulsar la plataforma en la nube GCP. Ambas opciones implican lo mismo: pagar por el trabajo de quienes escriben y mantienen el código. Eso es lo que él llama la única solución sostenible: pagar a los desarrolladores.

El caso de Ingress NGINX no es una excepción. Un conflicto similar estalló entre voluntarios del proyecto FFmpeg y los ingenieros de Google. Las exigencias de seguridad aumentaban y nadie facilitaba recursos para atenderlas. Lo irónico es que FFmpeg lo usan a diario miles de millones de personas: prácticamente en todos los navegadores, en plataformas de streaming, en televisores y en reproductores multimedia. El programa está en todas partes, pero su viabilidad depende de un puñado de voluntarios que nadie contrató ni financió.

Es un círculo vicioso que se viene advirtiendo desde hace tiempo. Todos han visto esa viñeta de xkcd donde Internet entero depende de un módulo insignificante escrito por un tipo de Nebraska. Ahora eso ya no es una hipérbole, sino la realidad. Y ese programador necesita comer, dormir y tener derecho a un día libre.

Ingress NGINX se va, pero con él desaparece la ilusión del «software de código abierto» gratuito. Es hora de dejar de fingir que los proyectos nacen y viven por sí mismos sin esfuerzo. O la comunidad empieza a pagar a quienes la alimentan, o ese alimento empezará a desaparecer uno tras otro.