В большинстве команд безопасность контейнеров сводится к двум крайностям: либо её нет вовсе, либо она живёт в виде отдельного сканера, отчёт которого никто не читает. Между этими полюсами есть рабочая схема — когда допуск образа в прод становится частью пайплайна, а не ручной проверкой перед релизом. Разберём, из каких этапов складывается такой цикл и как выстроить его так, чтобы он не тормозил разработку.

Этап 1. Манифест разрешённых базовых образов

Первый и самый дешёвый барьер — ограничить круг базовых образов, от которых можно наследоваться. Если каждый разработчик тянет latest с Docker Hub, никакой контроль дальше не спасёт: вы не знаете, что внутри, и не можете воспроизвести сборку. Заведите файл-манифест (YAML или JSON), где перечислены разрешённые образы с фиксированными тегами и, желательно, с digest.

  • Указывайте конкретные версии и digest, а не плавающие теги.
  • Фиксируйте источник: внутренний registry или проверенное зеркало.
  • Держите манифест в том же репозитории, что и CI-конфигурацию, — так изменения проходят ревью.
  • Настройте автоматическое обновление манифеста: новые версии базовых образов должны появляться не «когда вспомнят», а по расписанию с проверкой.

Типичная ошибка здесь — сделать манифест статичным. Через полгода в нём останутся образы, которые уже не поддерживаются, а разработчики начнут обходить ограничение через исключения. Манифест должен быть живым артефактом с владельцем и процессом обновления.

Этап 2. Сканирование и аттестация

После сборки образ проходит сканирование на уязвимости. Важно не просто получить отчёт, а превратить его в аттестацию — подписанное утверждение, что образ проверен и соответствует политике. Это принципиальный сдвиг: отчёт можно проигнорировать, аттестация становится условием допуска.

Критерии выбора сканера: поддержка вашего стека и форматов, скорость работы в CI, наличие базы уязвимостей с понятной частотой обновления, возможность задавать пороги (например, блокировать только critical и high с доступным фиксом). Пороги — ключевая настройка. Если блокировать всё подряд, пайплайн встанет через неделю, и его отключат.

  • Определите уровни, при которых сборка падает, а при которых создаётся тикет.
  • Учитывайте наличие исправления: уязвимость без фикса не должна блокировать релиз навсегда.
  • Храните результаты сканирования рядом с артефактом, а не в отдельной системе, куда никто не смотрит.
  • Подписывайте результат сканирования тем же ключом, что и сам образ, — так аттестация становится проверяемой.

Пример ошибки: команда настроила сканер, но пороги задал один человек «на глаз». Через месяц выяснилось, что половина сервисов собирается с исключениями, а исключения никто не ревьюил. Правило простое: любое исключение — с датой истечения и ответственным.

Этап 3. Подпись и admission-политики

Финальный барьер — на входе в кластер. Admission-контроллер (например, Kyverno или аналог) проверяет, что образ подписан и имеет аттестацию с результатами проверок. Если подписи нет — под не проходит, и никакие ручные обходы не помогают. Это то самое «годен», которое ставится автоматически.

Что стоит проверить в политике перед включением в прод:

  • Политика проверяет и подпись, и наличие аттестации, а не только одно из двух.
  • Есть режим аудита: сначала политика только логирует нарушения, потом блокирует.
  • Исключения оформлены явно и тоже проходят ревью.
  • Политика покрывает не только Deployment, но и другие workload-типы, которые вы используете.

Типичная ошибка — включить блокировку сразу во всех окружениях. Начните с аудита в staging, соберите список того, что не проходит, и только потом переводите в enforce. Иначе первый же деплой в пятницу вечером покажет, что половина сервисов собрана в обход пайплайна.

Как не превратить контроль в бюрократию

Главный риск такой схемы — она начинает работать против разработчиков. Признаки: сборка идёт дольше десяти минут, исключения оформляются быстрее, чем чинятся, а в чате появляется фраза «да забудь ты про этот сканер». Чтобы этого не случилось, держите три вещи под контролем.

Первое — скорость. Сканирование и подпись должны укладываться в минуты, а не в полчаса. Кэшируйте слои, не сканируйте то, что не изменилось. Второе — прозрачность. Разработчик должен видеть, почему образ не прошёл, и что конкретно сделать. Сообщение «policy violation» бесполезно; сообщение с именем уязвимости, версией пакета и ссылкой на фикс — работает. Третье — владелец процесса. У цикла контроля должен быть человек или команда, которые отвечают за манифест, пороги и разбор исключений. Без владельца схема деградирует за пару месяцев.

И последнее: не пытайтесь закрыть всё сразу. Начните с манифеста базовых образов — это даёт быстрый эффект при минимальных усилиях. Затем добавьте сканирование с мягкими порогами. И только когда процесс устоялся, включайте admission-политики в режиме аудита, а потом в enforce. Такой порядок позволяет команде привыкнуть к ограничениям постепенно, а вам — не получить саботаж на ровном месте.