Kubernetes v1.36: статические политики допуска, которые нельзя удалить

Если вы когда-либо пытались внедрить политику безопасности в группе кластеров Kubernetes, то наверняка сталкивались с классической проблемой курицы и яйца. Ваши политики допуска — это объекты API, а значит, они не существуют, пока кто-то их не создаст, и их может удалить любой, у кого есть соответствующие права. Всегда есть окно во время начальной загрузки кластера, когда политики ещё не активны, и нет способа предотвратить их удаление привилегированным пользователем. Kubernetes v1.36 представляет альфа-функцию, которая решает эту проблему: управление доступом на основе манифестов. Она позволяет определять вебхуки допуска и политики на основе CEL как файлы на диске, которые загружаются API-сервером при запуске, до того как он начнёт обрабатывать запросы.

Пробел, который мы закрываем

Большинство современных механизмов применения политик в Kubernetes работают через API. Вы создаёте ValidatingAdmissionPolicy или конфигурацию вебхука как объект API, и контроллер допуска подхватывает его. В стабильном состоянии это работает хорошо, но есть фундаментальные ограничения.

Во время начальной загрузки кластера существует разрыв между моментом, когда API-сервер начинает принимать запросы, и моментом создания и активации политик. Если вы восстанавливаетесь из резервной копии или переживаете отказ etcd, этот разрыв может быть значительным.

Также есть проблема самозащиты. Вебхуки допуска и политики не могут перехватывать операции с собственными конфигурационными ресурсами. Kubernetes пропускает вызов вебхуков для типов вроде ValidatingWebhookConfiguration, чтобы избежать циклических зависимостей. Это означает, что достаточно привилегированный пользователь может удалить ваши критически важные политики допуска, и в цепочке допуска не будет ничего, что могло бы его остановить. Мы — Kubernetes SIG API Machinery — хотели найти способ сказать: «эти политики всегда включены, точка».

Как это работает

Вы добавляете поле staticManifestsDir в файл AdmissionConfiguration, который уже передаёте API-серверу через флаг --admission-control-config-file. Укажите каталог, поместите туда YAML-файлы политик, и API-сервер загрузит их до начала обработки запросов.

Поддерживаются два типа политик: ValidatingAdmissionPolicyBinding (CEL-политики) и ValidatingWebhookConfiguration (вебхуки). Всё, что API-сервер находит в этом каталоге, считается статическим манифестом. Эти политики нельзя изменить или удалить через API — они существуют на диске и переживают перезапуск.

Если статическая политика конфликтует с динамической (созданной через API), приоритет отдаётся статической. Это гарантирует, что даже если кто-то попытается создать политику, противоречащую вашим требованиям, она будет проигнорирована.

Какие проблемы решает эта функция

Для администраторов кластеров это означает, что теперь можно гарантировать работу базовых политик безопасности с самого первого момента работы кластера. Например, можно запретить запуск контейнеров с привилегиями root, обязать наличие readiness-проб или ограничить доступ к определённым API-группам — и эти правила будут действовать ещё до того, как в кластере появится первый пользователь.

Для команд безопасности это инструмент, который позволяет реализовать принцип наименьших привилегий на уровне инфраструктуры. Статические политики становятся частью конфигурации API-сервера, и их нельзя обойти, даже имея права администратора кластера.

Разработчикам платформ стоит обратить внимание, что теперь можно создавать базовые политики, которые невозможно случайно или намеренно удалить. Это особенно важно в мультитенантных средах и regulated-индустриях, где требуется строгий аудит и неизменяемость политик.

Технические подробности и ограничения

На данный момент функция находится в альфа-стадии. Чтобы её включить, нужно установить флаг --feature-gates=StaticAdmissionControlPolicies=true на API-сервере. Важно понимать, что статические политики загружаются только из указанного каталога. API-сервер не отслеживает изменения файлов в реальном времени — для применения новой версии политики потребуется перезапуск API-сервера. Это сделано намеренно, чтобы сохранить предсказуемость и избежать race conditions.

Также стоит отметить, что статические политики не могут быть изменены через kubectl или любой другой клиент API. Единственный способ их обновить — изменить файлы на диске и перезапустить API-сервер. Это повышает безопасность, но требует более тщательного планирования изменений.

Кого затронет и как

Разработчики платформ и администраторы кластеров получат инструмент для создания неизменяемых политик. Это особенно актуально для организаций, которые управляют сотнями кластеров и хотят гарантировать единый уровень безопасности на всех этапах жизненного цикла.

Команды безопасности смогут внедрять политики, которые невозможно обойти даже при наличии прав суперпользователя в кластере. Это закрывает целый класс уязвимостей, связанных с удалением или изменением политик допуска.

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

Что будет дальше

Функция пока альфа, и её API может измениться. Команда SIG API Machinery планирует собрать отзывы от сообщества и, возможно, расширить список поддерживаемых типов политик. В будущем можно ожидать поддержки MutatingWebhookConfiguration и, возможно, других ресурсов. Также обсуждается возможность горячей перезагрузки статических манифестов без перезапуска API-сервера, но это потребует дополнительной работы над безопасностью и консистентностью.

Итог

Manifest-based admission control в Kubernetes v1.36 — это важный шаг к более безопасным и предсказуемым кластерам. Он решает давнюю проблему начальной загрузки политик и добавляет уровень защиты от их удаления. Если вы управляете Kubernetes-инфраструктурой, стоит присмотреться к этой функции уже сейчас, чтобы быть готовым к её стабилизации в будущих релизах.