В релизе Kubernetes v1.36 официально объявили старевшим (deprecated) поле
.spec.externalIPs. Эта функция существовала с первых версий K8s. Исторически поле использовалось для ручной привязки внешних IP к сервису. Однако API Kubernetes не проверяет права владения IP-адресом, поэтому есть вероятность нарваться на атаку.⚪️Вектор атаки: любой пользователь с правами на создание Service в любом Namespace может указать в
externalIPs чужой IP (например, адрес внешнего DNS, шлюза или соседнего сервиса).⚪️Результат:
kube-proxy перехватит этот трафик внутри кластера, что позволяет провести атаку Man-in-the-Middle (MITM) или устроить DoS. Уязвимость признана архитектурной («исправление невозможно»), поэтому функционал полностью удаляют.Таймлайн удаления:
— v1.36 (мы здесь): официальный deprecation. При отправке манифестов API возвращает предупреждения. Появился Feature Gate
AllowServiceExternalIPs (пока true).~ v1.40: Отключение по умолчанию. Флаг переводится в
false. kube-proxy перестает обрабатывать externalIPs, если администратор не включит его принудительно.~ v1.43: Полное удаление кода. Поддержка механизма полностью вырезается из
kube-proxy.~ v1.46: Финальная зачистка API-сервера.
На что мигрировать?
Если вы используете
externalIPs, у вас есть 3 безопасные альтернативы:⚪️для Bare-Metal: переход на
Service.spec.type: LoadBalancer с использованием MetalLB или Kube-vip. Они выделяют IP строго из доверенных пулов с помощью ARP/BGP.⚪️для L7/L4 трафика: использование Gateway API или классических Ingress-контроллеров. Доступ к публикации маршрутов здесь жестко разграничен через RBAC.
⚪️для простых задач: старый добрый
Service.spec.type: NodePort (выделение портов строго контролируется кластером).Проверить кластер на наличие уязвимых сервисов:
kubectl get svc -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"/"}{.metadata.name}{"\t"}{.spec.externalIPs}{"\n"}{end}' | grep -v '\[\]'@DevOpsKaz 😛