Сканирование в CI не замыкает цикл
Большинство команд уже сканирует образы в пайплайне. Это необходимо. Этого недостаточно.
Между build и runtime остаётся пространство, чтобы другой образ попал в кластер: повторно использованный tag, ручной deploy, среда, пропускающая тот же gate, вторичный registry. Если единственный барьер живёт в CI, API server Kubernetes по-прежнему принимает любой Pod, соответствующий манифесту.
Полезный вопрос не в том, сканируете ли вы. А в том, когда вы можете отклонить образ с доказательствами уязвимостей и явной политикой.
Что на самом деле решает admission control
ValidatingAdmissionWebhook выполняется, когда API server оценивает create или update. Если webhook возвращает allowed: false, объект не входит. Операторам не нужно читать отчёт постфактум.
Это превращает постуру по уязвимостям из отчёта в операционное решение: разрешить, предупредить или аудировать по заданным правилам.
Что делает KATANA
KATANA. наша open-source control plane для этого решения. До появления Pod она запрашивает настроенный scan backend (JFrog Xray и/или Amazon Inspector на ECR), применяет политики (deny, warn, audit), фиксирует detection и может обеспечить результат через нативный webhook Kubernetes.
На практике:
- политика живёт в SQLite или в CRD
ImagePolicy - evaluator выводит severity и применяет namespace-исключения при конфигурации
- режим dry-run показывает влияние без блокировки deploy
- есть UI на кластер и fleet-вид с метриками Prometheus по средам
API server остаётся компонентом, который блокирует. KATANA даёт оценку и доказательства.
Почему важен dry-run
Включение enforcement в первый день обычно создаёт политическое трение, а не техническое сомнение. Platform и product должны видеть, что было бы заблокировано, с каким сообщением и на каком образе, до ужесточения правила.
Dry-run превращает «это сломает production» в конкретный список находок и исключений. После этого deny. документированное решение, а не мнение.
Ограничения, которые стоит назвать
KATANA не заменяет сканер. Зависит от качества и покрытия backend (Xray, Inspector или другие интеграции). Сама по себе не решает подписанный supply chain, runtime-детекцию или сетевую постуру.
Её задача узкая: в момент admission соответствует ли этот образ политике, определённой организацией?
Как мы используем это с клиентами
В DevSecOps и работе над Kubernetes-платформой мы начинаем с этого вопроса. Оцениваем, что сканируется сегодня, что достигает кластера без того же контроля, и где admission gate даёт больше, чем ещё один отчёт.
KATANA. наш собственный tooling. Мы предоставляем его клиентам, когда задача. закрыть разрыв между сканированием и runtime.
Репозиторий: github.com/zpol/katana. Чтобы проверить admission образов на вашей платформе, запишитесь на встречу или см. DevSecOps & Automation.