Koray Oksay, посол CNCF, считает, что организации часто передают Kyverno в ведение команд безопасности, используя его для проверки настроек Kubernetes и блокировки контейнеров, работающих с правами root, или для обеспечения стандартов безопасности контейнеров, а затем оставляют без внимания значительную часть его возможностей. Согласно позиции Oksay, такое мысленное отнесение ограничивает Kyverno ролью «шлюза», блокирующего некорректные настройки, тогда как его можно использовать как базовый строительный блок, на котором платформенные команды создают свои сервисы и операционные правила.
Это мнение основано на опыте автора, начавшемся с выступления на конференции KCD Munich в 2023 году под названием «Защита рабочих нагрузок Kubernetes с помощью Kyverno». После трёх лет работы в производственных средах он говорит, что его интерес сместился к управлению, CEL и самообслуживанию платформ, а описание Kyverno как «движка политик» уже недостаточно, чтобы охватить весь его диапазон возможностей.
Почему классификации как инструмента безопасности недостаточно?
Oksay не отрицает функции Kyverno, связанные с безопасностью. Платформа может блокировать небезопасные настройки, обеспечивать соблюдение Pod Security Standards и проверять подписи образов контейнеров. Однако её односторонняя связь с безопасностью закрепляет модель, в которой политика воспринимается как барьер, основной целью которого является отказ, а успех измеряется количеством предотвращённых развёртываний.
Вместо этого автор выделяет четыре основные функции Kyverno: проверку, изменение, генерацию и проверку образов. Функция проверки непосредственно относится к модели барьера, тогда как изменение меняет ресурсы до их добавления в кластер, генерация создаёт новые ресурсы в ответ на определённые события, а проверка образов сосредоточена на формировании доверия к ним, а не только на блокировке угроз. Поэтому он считает, что три из четырёх функций имеют созидательный характер, однако многие организации используют только политики проверки.
Что означает «ключевой компонент платформы»?
Oksay использует выражение «ключевой компонент» в смысле, близком к его употреблению в языках программирования: это небольшой и понятный строительный блок, который можно комбинировать для создания более крупных систем. Чтобы такой блок действительно выполнял роль платформенного компонента, он должен скрывать сложность от разработчиков, обеспечивать автоматические гарантии, интегрироваться с другими блоками и быть доступным в режиме самообслуживания, а не зависеть от ручных запросов или очередей поддержки.
В этом смысле политики Kyverno похожи на такие компоненты, как Pods, Services, ConfigMaps и композиции Crossplane. Они превращают правила, принятые организацией, в автоматическое поведение внутри платформы.
Как его используют платформенные команды?
- Подготовка пространств имён: при создании пространства имён Kyverno может сгенерировать NetworkPolicy, ResourceQuota, LimitRange и стандартные RoleBindings, чтобы пространство появлялось уже подготовленным и разработчику не приходилось помнить список ручных шагов.
- Внедрение контейнеров-помощников: на этапе допуска можно добавлять в спецификации Pod агентов мониторинга, сетевых агентов или контейнеры синхронизации секретов, сохраняя файл Deployment простым.
- Перезапись ссылок на образы: ссылку, например nginx:1.25, можно преобразовать в mirror.internal/nginx:1.25, чтобы операции загрузки проходили через внутреннее зеркало, вместо того чтобы требовать от каждого разработчика вручную добавлять префикс.
- Добавление запросов ресурсов по умолчанию: вместо блокировки Pods, в которых не указаны запросы CPU и памяти, можно внедрить подходящие значения, а затем при необходимости изменить их.
- Назначение тегов владения: можно добавлять теги команды, центра затрат и среды, когда значения очевидны, или делать их обязательными, если неопределённость имеет существенное значение.
Что меняется на практике?
Все эти варианты использования объединяет одна идея: превращение организационного принципа в невидимую автоматическую гарантию. Правило может быть связано с безопасностью, например запрет контейнеров с повышенными привилегиями, операционным аспектом, например обязательными ограничениями ресурсов, или финансами, например привязкой каждого ресурса к тегу центра затрат. Вместо того чтобы оставаться в вики, контрольных списках или знаниях одного инженера, эти правила становятся политикой, записанной в виде кода, сохранённой в Git и применяемой с помощью инструментов GitOps и Kyverno.
Согласно этой точке зрения, политику следует рассматривать как интерфейс платформы для выражения намерений организации. При таком подходе функции Kyverno превращаются в разные уровни: проверка обеспечивает защитные барьеры, изменение формирует для разработчиков «проторённые дорожки», генерация предоставляет шаблоны или начальную подготовку, а проверка образов создаёт доверие.
Команды также будут воспринимать политики как продукты, у которых есть версии, пользователи, циклы вывода из эксплуатации и отслеживаемые исключения. Развёртывание политики может начинаться с аудита, затем переходить к предупреждениям и после этого — к постепенному принудительному применению. Автор также указывает на возможные проблемы координации, когда политика изменяет ресурс, который Argo CD или Flux считает принадлежащим себе, что может привести к циклам синхронизации.
Вывод Oksay заключается в том, что восприятие Kyverno исключительно как инструмента безопасности скрывает значительную часть его интерфейса и возможностей. По его мнению, это не страж, стоящий у входа в кластер, а слой, связывающий представления платформенной команды с фактическим поведением ресурсов и приложений.