Что меняет Kubernetes#
Часть CVE Kubernetes скоро будет выглядеть более актуальной, хотя сам риск не появился заново. Комитет Kubernetes Security Response Committee сообщил, что 1 июня 2026 года обновит несколько старых записей CVE: раньше они неточно показывали, что проблемы остаются неисправленными и затрагивают все версии.
Практический эффект простой: сканеры уязвимостей могут начать находить то, что раньше пропускали. Это не означает новую кампанию эксплуатации. Это означает, что метаданные приводят в соответствие с реальным состоянием безопасности проекта.
Проект Kubernetes пишет, что недавняя работа над официальными файлами Open Source Vulnerabilities выявила расхождения в старых CVE. Некоторые записи намекали, что существует исправленная версия, или неверно описывали диапазон затронутых версий. Для случаев из публикации это было ошибкой.
Речь не об обычных багах, которые ждут патча. Kubernetes описывает их как архитектурные компромиссы. Полное исправление в коде сломало бы поведение, на которое опираются легитимные кластеры и интеграции.
1 июня 2026 года проект планирует обновить затронутые записи CVE так, чтобы они корректно показывали: затронуты все версии Kubernetes. В публикации также сказано, что еще одна неисправленная CVE уже имеет правильную запись «все версии», но ее обновят, чтобы использовать более стандартизированный формат номера версии.
Это важное различие. Инструменты безопасности читают диапазоны версий. Если диапазон говорит, что исправленная версия существует, хотя полного исправления нет, сканеры могут давать ложноотрицательные результаты. Администраторы могут решить, что кластер «перерос» риск, хотя это не так.
Это исправление метаданных, а не выпуск патча. Операционная ответственность остается на владельцах кластеров.
Три устойчивых риска#
Публикация Kubernetes выделяет три старые уязвимости, которые проект по-прежнему не исправил. Технические детали лучше отслеживать в связанных GitHub issues, но общий шаблон безопасности везде один: Kubernetes разрешает поведение, полезное в реальных внедрениях, но опасное, если слишком широко раздать соответствующие права.
Redirect в admission webhook#
Одна проблема связана с тем, что kube-apiserver следует HTTP redirect при взаимодействии с admission webhook. Если субъект может настраивать AdmissionWebhookConfiguration, он может перенаправить запросы API server во внутренние или приватные сети.
Kubernetes пишет, что ограничение такого поведения сломало бы стандартное поведение HTTP client, которое используют легитимные интеграции. Поэтому это меньше похоже на пропущенную проверку границ и больше — на проблему границы доверия: право настраивать webhooks само по себе чувствительное, а redirect расширяет, до чего это право может дотянуться.
Рекомендованные меры — операционные. Держите уровень логирования API server ниже 10, чтобы тела ответов не попадали в логи. Отключите dynamic profiling через --profiling=false, чтобы предотвратить несанкционированное изменение уровня логирования.
DNS race в прокси API server#
Вторая проблема — DNS time-of-check to time-of-use race в прокси API server. Система проверяет IP после DNS resolution, а затем выполняет еще один resolution уже для фактического соединения. Если атакующий может изменить результат между этими двумя моментами, IP-ограничения можно обойти.
Kubernetes пишет, что полное исправление потребовало бы закреплять resolved IPs. На бумаге это выглядит аккуратно, но конфликтует со split-horizon DNS, динамическими IP-средами и другими схемами развертывания, которые Kubernetes должен поддерживать.
Рекомендованная мера — использовать локальный кэширующий DNS resolver, например dnsmasq, на узлах API server и настроить API server на работу с ним. Цель — сделать так, чтобы ответ, использованный для проверки, совпадал с ответом, использованным для соединения.
Между namespace через Endpoints#
Третья проблема касается API objects Endpoints и EndpointSlice. Так как пользователи могут вручную указывать IP-адреса, эти objects можно использовать, чтобы направить LoadBalancer или Ingress на backends в других namespaces.
Kubernetes называет это design flaw, но это также возможность, от которой зависят многие сетевые инструменты и operators. Простое удаление такого поведения сломало бы реальные системы.
Мера защиты — контроль доступа. Администраторам стоит ограничить write access к Endpoints и EndpointSlices. Kubernetes отмечает, что начиная с версии 1.22 режим авторизации RBAC больше не включает эти permissions в default ClusterRoles. Это помогает новым кластерам, созданным на Kubernetes v1.22 или позже. Но это не очищает автоматически каждый обновленный кластер.
Для кластеров, обновленных со старых версий, администраторам нужно вручную проверить и привести в порядок RBAC permissions.
Почему сканеры могут начать шуметь#
Самым заметным итогом обновления 1 июня может стать рост числа findings в сканерах. Они появятся потому, что записи CVE начнут отражать реальный диапазон затронутых версий. Это неприятно, но лучше, чем тихий пропуск.
Это также полезное напоминание о том, что метаданные CVE могут и не могут сказать. Finding в сканере не всегда означает новый риск. Чистый результат сканера не доказывает, что архитектурная exposure устранена. Качество исходной записи имеет значение.
В этом случае Kubernetes явно выбирает точность вместо комфорта. Старые записи позволяли легче игнорировать часть рисков. Обновленные записи должны сделать их заметнее.
Администраторам не стоит превращать это в срочные tickets на патч, если среда не дает недоверенным пользователям соответствующие privileges в control plane. Более полезная реакция — сопоставить каждую CVE с реальными границами доверия: кто может настраивать admission webhooks, кто может использовать прокси API server, кто может писать Endpoints или EndpointSlices.
Что проверить администраторам#
Рекомендации Kubernetes ведут к defense-in-depth, а не к одному шагу обновления.
Практические проверки:
- Проверьте, кто может создавать или изменять admission webhook configurations.
- Держите уровень логирования API server ниже 10, особенно там, где в response bodies могут быть чувствительные данные.
- Отключите dynamic profiling через
--profiling=false, если нет понятной операционной необходимости. - Разверните dnsmasq или похожий локальный caching resolver на узлах control plane для DNS race condition в API server.
- Проверьте RBAC roles на слишком широкий write access к Endpoints и EndpointSlices.
- Отдельно проверьте кластеры, обновленные с Kubernetes до версии 1.22: старые permissions могли сохраниться.
- Тестируйте mitigations вне production перед изменением поведения control plane.
Примечание про RBAC легко пропустить. Kubernetes пишет, что default ClusterRoles изменились для кластеров, созданных на v1.22, но обновленные кластеры могут сохранить старую форму permissions. Если сканер отмечает проблему с Endpoints, полезный вопрос не только «какая версия Kubernetes?». Важнее спросить: «какие permissions пережили путь обновления?»
Чего не стоит утверждать#
Публикация не говорит, что у этих проблем появились новые исправления. Она не заявляет о новой эксплуатации. Она не называет новую версию Kubernetes, которая устраняет риск.
Она говорит, что записи были ошибочными или неполными, и проект исправляет их, чтобы инструменты безопасности и администраторы яснее видели сохраняющуюся exposure.
Это менее драматично, чем новый zero-day, но важнее для долгоживущей инфраструктуры. Кластеры Kubernetes часто несут годы истории обновлений, drift в RBAC, предположения controllers и зависимости интеграций. Архитектурные CVE живут именно в этой зоне. Они не исчезают от ожидания патча, который, по словам проекта, сломал бы фундаментальное поведение.
Правильная реакция узкая и конкретная: проверьте, выдает ли ваш кластер рискованные capabilities, примените задокументированные mitigations там, где они подходят, и ожидайте, что после исправления записей CVE сканеры станут громче.