Kubernetes 1.36 deprecates Service externalIPs: причины, риски и альтернативы

В релизе Kubernetes 1.36 команда разработчиков объявила поле .spec.externalIPs для Service устаревшим. Это решение направлено на повышение безопасности платформы: в будущих версиях функциональность будет полностью удалена, а пока пользователям рекомендуется перейти на альтернативные решения. Поле externalIPs изначально задумывалось как простой способ назначить Service внешний IP в необлачных кластерах, но его реализация оказалась опасной из-за отсутствия проверок прав доступа. Любой пользователь с правами на создание или обновление Service может указать произвольный IP-адрес и перехватить трафик, что ведет к серьезным атакам, описанным в уязвимости CVE-2020-8554.

История проблемы и уязвимость CVE-2020-8554

Проблема известна с 2020 года, когда была зарегистрирована уязвимость CVE-2020-8554. Она позволяет злоумышленнику, имеющему доступ к API Kubernetes, перенаправить трафик Service на любой IP-адрес, включая адреса других сервисов или внешних узлов. Это открывает путь к перехвату данных, атакам типа "человек посередине" и другим эксплуатациям. Уже тогда Kubernetes рекомендовал отключать externalIPs, но полное удаление откладывалось из-за обратной совместимости.

Почему deprecation произошел только сейчас?

Сообщество долго обсуждало, как безопасно отказаться от externalIPs. В версии 1.21 появился admission controller DenyServiceExternalIPs, который блокирует использование этого поля, но по умолчанию он не включался — SIG Network посчитала, что такое изменение будет слишком ломающим для существующих кластеров. С тех пор появились зрелые альтернативы: MetalLB, kube-vip и Gateway API. Они предоставляют безопасную балансировку нагрузки без рисков, присущих externalIPs. В Kubernetes 1.36 команда решила, что настало время двигаться вперед, и объявила поле deprecated.

Что именно deprecated и кого это касается?

Важно понимать: deprecated объявлено только поле .spec.externalIPs в Service API. Оно не имеет отношения к ExternalIP как типу адреса в Node.status.addresses или к столбцу EXTERNAL-IP в выводе kubectl для Service типа LoadBalancer. Если вы не используете поле externalIPs в своих манифестах Service, вас это изменение не затрагивает. Тем не менее, стоит проверить свои конфигурации. Если вы задаете externalIPs, пора планировать миграцию. В будущих версиях kube-proxy перестанет обрабатывать такие IP, а тесты соответствия Kubernetes потребуют, чтобы реализации не поддерживали эту функцию.

Какие риски несет использование externalIPs?

Поле externalIPs позволяло указать список дополнительных IP-адресов, на которых Service будет отвечать. Это было удобно для небольших кластеров без облачного балансировщика, но создавало вектор атаки: любой пользователь с правами на создание Service мог указать чужой IP и перенаправить трафик. В результате злоумышленник мог перехватывать данные, предназначенные для других сервисов, или проводить атаки на внешние узлы. Уязвимость CVE-2020-8554 классифицируется как среднего уровня опасности, но в сочетании с другими уязвимостями может привести к полной компрометации кластера.

Альтернативы externalIPs

Сообщество Kubernetes разработало несколько безопасных альтернатив, которые не требуют доверия ко всем пользователям и предоставляют гибкую балансировку нагрузки.

MetalLB для bare-metal кластеров

MetalLB — популярное решение для bare-metal кластеров, реализующее протоколы ARP/NDP или BGP для объявления Service IP. Оно безопасно, не требует доверия ко всем пользователям и активно поддерживается сообществом. MetalLB интегрируется с Kubernetes через стандартные механизмы и не имеет описанных проблем безопасности. Для установки достаточно применить манифест или использовать Helm-чарт.

kube-vip для виртуальных IP

kube-vip — еще один проект, предоставляющий виртуальные IP для control plane и Service. Он использует VRRP и BGP, интегрируется с Kubernetes и не имеет описанных проблем безопасности. kube-vip может работать как в режиме control plane, так и в режиме Service, обеспечивая высокую доступность. Его настройка требует некоторого опыта, но документация проекта подробна.

Gateway API как современный стандарт

Gateway API — более новый и гибкий стандарт, который постепенно заменяет Ingress и может использоваться для балансировки нагрузки. Он проектировался с учетом современных требований безопасности и не имеет проблем, присущих externalIPs. Gateway API поддерживается многими реализациями, включая Contour, Istio и другие. Переход на Gateway API может потребовать изменения архитектуры, но в долгосрочной перспективе это наиболее перспективное решение.

Как мигрировать с externalIPs

Если вы используете externalIPs, начните с аудита текущих конфигураций. Определите, какие Service используют это поле, и замените их на одну из альтернатив. Для bare-metal кластеров рекомендуется MetalLB или kube-vip. Для кластеров с поддержкой облачных балансировщиков используйте type: LoadBalancer. Если вы не можете отказаться от externalIPs немедленно, включите admission controller DenyServiceExternalIPs, чтобы предотвратить создание новых опасных Service. Но в долгосрочной перспективе миграция неизбежна.

Что будет, если не мигрировать?

В будущих версиях Kubernetes kube-proxy перестанет обрабатывать externalIPs, и Service с этим полем перестанут работать корректно. Кроме того, тесты соответствия Kubernetes будут требовать, чтобы реализации не поддерживали эту функцию, что может привести к проблемам при сертификации. Поэтому рекомендуется начать миграцию как можно раньше.

Заключение

Deprecation externalIPs в Kubernetes 1.36 — это важный шаг к безопасности платформы. Уязвимость CVE-2020-8554 наконец получает должное внимание, а сообщество получает четкий сигнал: пора переходить на современные и безопасные решения. Если вы используете externalIPs, начните планировать миграцию уже сегодня, чтобы избежать проблем в будущих версиях. Используйте MetalLB, kube-vip или Gateway API — они предоставляют безопасную и гибкую балансировку нагрузки без рисков, присущих устаревшему полю.