GitOps политика Kubernetes становится управляемой, когда enforcement встроен в поток доставки. Связка Kyverno и Argo CD закрывает этот разрыв на уровне admission.
Когда кластер начинает принимать ресурсы, созданные вне контролируемого процесса, требуется управления состоянием. Argo CD решает задачу декларативного управления состоянием, но не валидирует сами манифесты на соответствие политикам. В результате misconfiguration и небезопасные настройки проходят в production, если они синтаксически корректны. Это особенно заметно в multi-tenant средах, где разные команды коммитят изменения с разным уровнем зрелости.
Решение строится вокруг Kyverno как policy engine для Kubernetes. Он работает на уровне admission controller и проверяет каждый ресурс до его создания. Ключевой момент — политики описываются в стандартном Kubernetes YAML. Это устраняет разрыв между конфигурацией и governance: те же GitOps-процессы применяются и к инфраструктуре, и к правилам. В связке с Argo CD это даёт единый поток: политики версионируются, проходят review и автоматически применяются. Компромисс здесь очевиден: строгие политики могут блокировать деплой и замедлять delivery, поэтому вводится режим Audit как промежуточный этап.
Реализация опирается на App-of-Apps паттерн в Argo CD. Один root application управляет набором дочерних приложений, каждое из которых разворачивает отдельный компонент через Helm. Kyverno устанавливается как отдельное приложение с использованием официального Helm chart, обёрнутого в локальный chart. Важно, что применяется sync-wave аннотация: сначала разворачивается сам Kyverno, затем политики. Без этого порядок нарушается, и политики не применяются.
Есть несколько технических нюансов, которые влияют на стабильность:
- ServerSideApply=true используется из-за большого размера CRD Kyverno, который может превышать лимиты client-side apply
- IncludeMutationWebhook=true предотвращает ложные OutOfSync состояния, так как Kyverno может мутировать ресурсы
- ServerSideDiff=true улучшает сравнение состояний, учитывая изменения на стороне admission
Политики разворачиваются отдельным приложением, также через Helm. Используется официальный kyverno-policies chart как зависимость. Базовая конфигурация включает Pod Security Standard на уровне baseline. Это компромиссный выбор: блокируются очевидные риски, такие как privileged контейнеры или host networking, но сохраняется совместимость с большинством workloads. Режим validationFailureAction изначально выставляется в Audit, чтобы собрать сигналы о нарушениях без блокировки.
Дополнительно предусмотрен слой кастомных политик через директорию templates/. Это важный архитектурный момент: стандартные политики и специфичные для организации правила разделены, но проходят через один pipeline. После коммита Argo CD автоматически синхронизирует изменения, а Kyverno начинает их применять без ручных действий.
Хороший пример — запрет использования externalIPs в Service. Это известный вектор атаки (CVE-2020-8554), позволяющий перехватывать трафик. Политика Kyverno валидирует отсутствие этого поля. В режиме Enforce такой ресурс просто не будет создан. В режиме Audit — попадёт в отчёт как нарушение.
Результат — смещение контроля влево (shift-left) без изменения привычного GitOps-потока. Если политика нарушена в Enforce режиме, Argo CD помечает приложение как OutOfSync или Degraded и показывает ошибку валидации. Это делает проблемы видимыми на этапе синхронизации, а не после инцидента. В Audit режиме команды получают отчёты через PolicyReport и ClusterPolicyReport, что позволяет оценить влияние перед ужесточением правил.
Метрики в исходном материале не приводятся, но поведенческий эффект очевиден: система перестаёт принимать неконсистентные или небезопасные ресурсы. При этом сохраняется прозрачность изменений через Git. Такой подход выглядит как эволюционное усиление GitOps, где политика становится частью декларативного состояния, а не внешним процессом контроля.