Kyverno
Тема дорожной карты · Kubernetes
Kyverno — нативный для Kubernetes движок политик, валидирующий, мутирующий и генерирующий ресурсы Kubernetes с помощью политик, выраженных как пользовательские ресурсы Kubernetes, а не отдельный язык политик. Ресурс ClusterPolicy или Policy Kyverno определяет rules с блоками match и validate/mutate/generate, позволяя командам платформы применять правила: требовать от всех Deployment задания resources.requests и resources.limits, автоматически внедрять sidecar-контейнеры или генерировать стандартные NetworkPolicy для новых пространств имён. Kyverno интегрируется с kube-apiserver как admission-вебхук — развёртывается через kubectl apply или Helm-чарт — и его политики управляются стандартными командами kubectl: kubectl get clusterpolicy и kubectl describe policy. Отчёты о политиках отображаются через CRD PolicyReport и ClusterPolicyReport, интегрирующиеся с дашбордами Grafana и оповещениями через Prometheus. Как альтернатива OPA Gatekeeper, Kyverno ценится за чисто декларативное написание политик на YAML и тесную интеграцию с GitOps-рабочими процессами на базе Argo CD и Flux.
Как это работает
Kyverno в Kubernetes слоится через несколько контролей: RBAC (кто может делать что на каких ресурсах), Network Policies (какие pods могут общаться с какими), Pod Security Standards (ограничения privileged-операций), admission controllers (валидируют/мутируют ресурсы до persistence), underlying container runtime sandbox. Defence-in-depth: предполагайте, что любой single control будет обойдён, и проектируйте несколько слоёв.
Когда применять
Внедряйте Kyverno с создания кластера, не retrofit-ом позже — добавление RBAC в permissive кластер ломает десятки нагрузок. Начните с restrictive defaults и давайте доступ по нужде (least-privilege); применяйте NetworkPolicies в default-deny режиме; включайте PSS на уровне namespace. Регулируемые отрасли (банки, медицина) требуют это с дня 1; consumer-приложения выигрывают от этого до первого production-инцидента.
Типичные ошибки
Security-ловушки: cluster-admin role выдан разработчикам (полная власть; одна плохая команда сносит prod); image pull из ненадёжных registries без верификации подписи; serviceaccount tokens auto-mount в каждом pod (network access к API = lateral movement); пропуск CIS Kubernetes Benchmark-аудитов. Регулярный pentest находит реальные проблемы до того, как их найдут атакующие.