OPA Gatekeeper
Тема дорожной карты · Kubernetes
OPA Gatekeeper — admission-контроллер Kubernetes, применяющий политики к ресурсам Kubernetes с использованием движка Open Policy Agent (OPA) и языка политик Rego; зарегистрирован в kube-apiserver как validating и mutating вебхук. Политики выражаются как CRD ConstraintTemplate, определяющие параметризованные правила Rego, и CRD Constraint, инстанцирующие эти шаблоны с конкретными параметрами применения — например, требование установки limits ресурсов для всех Pod'ов или блокировка образов из ненадёжных реестров. OPA Gatekeeper может работать в режиме deny (жёсткая блокировка несовместимых ресурсов), dryrun (аудит существующих ресурсов без отклонения) или warn (отображение нарушений политики без блокировки admission). Результаты аудита хранятся в полях status.violations объектов Constraint, запрашиваемых через kubectl get constraints и интегрируемых с Prometheus для оповещений о нарушениях через дашборды Grafana. OPA Gatekeeper устанавливается через Helm-чарт или kubectl apply и является CNCF-проектом, широко используемым наряду с Kyverno как два доминирующих движка политик в экосистеме Kubernetes.
Как это работает
OPA Gatekeeper в Kubernetes слоится через несколько контролей: RBAC (кто может делать что на каких ресурсах), Network Policies (какие pods могут общаться с какими), Pod Security Standards (ограничения privileged-операций), admission controllers (валидируют/мутируют ресурсы до persistence), underlying container runtime sandbox. Defence-in-depth: предполагайте, что любой single control будет обойдён, и проектируйте несколько слоёв.
Когда применять
Внедряйте OPA Gatekeeper с создания кластера, не 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 находит реальные проблемы до того, как их найдут атакующие.