- 26,501
- 46
- 8 Ноя 2022
Ключевой компонент Kubernetes поддерживали два человека на энтузиазме — теперь они сдались.
KubeCon в Атланте собрал множество громких анонсов, касающихся Kubernetes, но одна из самых значимых новостей прошла практически незамеченной. Один из старейших и наиболее широко используемых компонентов — контроллер Ingress NGINX — официально признан устаревающим. Проект прекратит своё существование в марте 2026 года. После этой даты не будет выходить ни новых версий, ни заплаток, ни исправлений, связанных с безопасностью.
Ingress NGINX — это контроллер входящего трафика для кластеров Kubernetes . Он играет роль обратного прокси: перенаправляет внешние HTTP- и HTTPS-запросы к нужным внутренним сервисам в зависимости от заданных правил, включая домены, пути и TLS-конфигурацию. Его задачей было обеспечить надёжную маршрутизацию и равномерное распределение нагрузки. На практике через него проходил весь входящий трафик, и от корректной настройки зависела стабильность множества приложений. Именно поэтому его популярность оставалась высокой — он использовался повсеместно, особенно в продуктивных средах, где требовалась предсказуемость и контроль.
Несмотря на ключевую роль в экосистеме Kubernetes, проект долгое время держался буквально на энтузиазме пары человек. Поддержкой и развитием занимались один-два разработчика в свободное от основной работы время. Это продолжалось годами: будни, вечера, выходные — всё уходило на патчи, улучшения и закрытие багов. В прошлом году они объявили о намерении свернуть проект и параллельно начать разработку нового контроллера вместе с сообществом Gateway API. Однако даже такой прозрачный и заранее озвученный план не вдохновил других участников сообщества подключиться к работе: ни в поддержку Ingress NGINX, ни в развитие предполагаемой замены под названием InGate никто заметно не включился.
Ситуация приняла более острый оборот после того, как компания Wix обнаружила в проекте критическую уязвимость . Согласно их отчёту, эксплойт позволял злоумышленнику не просто вмешаться в работу кластера, а выполнить произвольный код и получить доступ ко всем конфиденциальным данным, включая секреты из разных namespace . Это означало полный компромисс всей платформы, на которой базировались приложения. После таких выводов оставлять компонент без активной поддержки стало невозможно даже теоретически.
Решение о прекращении жизненного цикла Ingress NGINX вызвало у части пользователей резкую реакцию. Некоторые выражали возмущение тем, что на сворачивание проекта отведён срок, который кажется недостаточным для переписывания документации и переезда на альтернативные решения. Разумеется, в крупных компаниях и инфраструктурах с высокой сложностью подобные миграции требуют месяцев работы. Однако в ответ один из ключевых разработчиков Kubernetes Тим Хокин напомнил, что разработчики Ingress NGINX — не наёмные сотрудники, а добровольцы, которые годами работали бесплатно. Он указал, что в течение двух лет с момента объявления о возможной остановке проекта почти никто не выразил желания взять на себя его поддержку, и в этой ситуации закрытие становится неизбежным.
Проблема, однако, не сводится к одному лишь небезопасному компоненту. Уязвимости возникают регулярно — этим не удивить даже самых спокойных инженеров. Корень проблемы — в модели, по которой корпоративный мир взаимодействует с open source. Подавляющее большинство компаний пользуется этими инструментами, но почти никто не участвует в их развитии.
Уильям Морган, возглавляющий компанию Buoyant, сформулировал два реалистичных пути: либо проект поддерживается компанией, которая зарабатывает напрямую на его продаже, как это делает сама Buoyant, либо — спонсируется корпорацией, для которой его существование критично, как Google финансирует Kubernetes в рамках продвижения облачной платформы GCP. Оба варианта подразумевают одно: оплата работы тех, кто пишет и сопровождает код. Именно это он называет единственно устойчивым решением — платить разработчикам.
Ситуация с Ingress NGINX не исключение. Похожий конфликт разгорелся между волонтёрами из проекта FFmpeg и инженерами Google. Требования по безопасности множились, а ресурсов на их выполнение никто не предоставлял. Ирония в том, что FFmpeg ежедневно используется миллиардами людей — практически во всех браузерах, на потоковых платформах, в телевизорах и медиаплеерах. Программа присутствует повсюду, но её жизнеспособность зависит от горстки добровольцев, которых никто не нанимал и не финансирует.
Это порочный круг, о котором давно предупреждают. Все видели ту самую карикатуру xkcd, где весь интернет опирается на один неприметный модуль, написанный каким-то парнем из Небраски. Только теперь это не гипербола, а реальность. И этот программист хочет есть, спать и иметь право на выходной.
Ingress NGINX уходит, но вместе с ним исчезает иллюзия о «бесплатном» open source . Пора перестать делать вид, что проекты сами по себе рождаются и живут без усилий. Либо сообщество начнёт платить тем, кто его кормит, либо эта пища начнёт исчезать одна за другой.
KubeCon в Атланте собрал множество громких анонсов, касающихся Kubernetes, но одна из самых значимых новостей прошла практически незамеченной. Один из старейших и наиболее широко используемых компонентов — контроллер Ingress NGINX — официально признан устаревающим. Проект прекратит своё существование в марте 2026 года. После этой даты не будет выходить ни новых версий, ни заплаток, ни исправлений, связанных с безопасностью.
Ingress NGINX — это контроллер входящего трафика для кластеров Kubernetes . Он играет роль обратного прокси: перенаправляет внешние HTTP- и HTTPS-запросы к нужным внутренним сервисам в зависимости от заданных правил, включая домены, пути и TLS-конфигурацию. Его задачей было обеспечить надёжную маршрутизацию и равномерное распределение нагрузки. На практике через него проходил весь входящий трафик, и от корректной настройки зависела стабильность множества приложений. Именно поэтому его популярность оставалась высокой — он использовался повсеместно, особенно в продуктивных средах, где требовалась предсказуемость и контроль.
Несмотря на ключевую роль в экосистеме Kubernetes, проект долгое время держался буквально на энтузиазме пары человек. Поддержкой и развитием занимались один-два разработчика в свободное от основной работы время. Это продолжалось годами: будни, вечера, выходные — всё уходило на патчи, улучшения и закрытие багов. В прошлом году они объявили о намерении свернуть проект и параллельно начать разработку нового контроллера вместе с сообществом Gateway API. Однако даже такой прозрачный и заранее озвученный план не вдохновил других участников сообщества подключиться к работе: ни в поддержку Ingress NGINX, ни в развитие предполагаемой замены под названием InGate никто заметно не включился.
Ситуация приняла более острый оборот после того, как компания Wix обнаружила в проекте критическую уязвимость . Согласно их отчёту, эксплойт позволял злоумышленнику не просто вмешаться в работу кластера, а выполнить произвольный код и получить доступ ко всем конфиденциальным данным, включая секреты из разных namespace . Это означало полный компромисс всей платформы, на которой базировались приложения. После таких выводов оставлять компонент без активной поддержки стало невозможно даже теоретически.
Решение о прекращении жизненного цикла Ingress NGINX вызвало у части пользователей резкую реакцию. Некоторые выражали возмущение тем, что на сворачивание проекта отведён срок, который кажется недостаточным для переписывания документации и переезда на альтернативные решения. Разумеется, в крупных компаниях и инфраструктурах с высокой сложностью подобные миграции требуют месяцев работы. Однако в ответ один из ключевых разработчиков Kubernetes Тим Хокин напомнил, что разработчики Ingress NGINX — не наёмные сотрудники, а добровольцы, которые годами работали бесплатно. Он указал, что в течение двух лет с момента объявления о возможной остановке проекта почти никто не выразил желания взять на себя его поддержку, и в этой ситуации закрытие становится неизбежным.
Проблема, однако, не сводится к одному лишь небезопасному компоненту. Уязвимости возникают регулярно — этим не удивить даже самых спокойных инженеров. Корень проблемы — в модели, по которой корпоративный мир взаимодействует с open source. Подавляющее большинство компаний пользуется этими инструментами, но почти никто не участвует в их развитии.
Уильям Морган, возглавляющий компанию Buoyant, сформулировал два реалистичных пути: либо проект поддерживается компанией, которая зарабатывает напрямую на его продаже, как это делает сама Buoyant, либо — спонсируется корпорацией, для которой его существование критично, как Google финансирует Kubernetes в рамках продвижения облачной платформы GCP. Оба варианта подразумевают одно: оплата работы тех, кто пишет и сопровождает код. Именно это он называет единственно устойчивым решением — платить разработчикам.
Ситуация с Ingress NGINX не исключение. Похожий конфликт разгорелся между волонтёрами из проекта FFmpeg и инженерами Google. Требования по безопасности множились, а ресурсов на их выполнение никто не предоставлял. Ирония в том, что FFmpeg ежедневно используется миллиардами людей — практически во всех браузерах, на потоковых платформах, в телевизорах и медиаплеерах. Программа присутствует повсюду, но её жизнеспособность зависит от горстки добровольцев, которых никто не нанимал и не финансирует.
Это порочный круг, о котором давно предупреждают. Все видели ту самую карикатуру xkcd, где весь интернет опирается на один неприметный модуль, написанный каким-то парнем из Небраски. Только теперь это не гипербола, а реальность. И этот программист хочет есть, спать и иметь право на выходной.
Ingress NGINX уходит, но вместе с ним исчезает иллюзия о «бесплатном» open source . Пора перестать делать вид, что проекты сами по себе рождаются и живут без усилий. Либо сообщество начнёт платить тем, кто его кормит, либо эта пища начнёт исчезать одна за другой.
- Источник новости
- www.securitylab.ru
