Как выбрать защиту контейнеров и Kubernetes: критерии и чек-лист

Короткий ответ: сначала определите, какой стек нужно закрыть — Docker, «голый» Kubernetes, OpenShift или отечественная платформа контейнеризации, — и убедитесь, что кандидат поддерживает именно его, а не общий Kubernetes «в теории». Дальше проверьте, закрывает ли продукт все три стадии жизненного цикла: сканирование образов на CVE и секреты ещё в CI/CD, admission control при деплое в кластер и runtime-детект аномалий у уже запущенных контейнеров.

Затем сверьте интеграцию с вашим пайплайном сборки и реестром образов, для КИИ и госсектора — статус сертификата ФСТЭК у конкретного продукта, и только в конце сравнивайте лицензирование и совокупную стоимость владения.

Безопасность контейнеров (container security) — класс средств защиты, который закрывает специфичные для контейнерных сред риски: уязвимый или заражённый образ, некорректно настроенный оркестратор и аномальное поведение уже запущенного контейнера. Это не модуль антивируса «под новую технологию», а отдельная модель угроз, потому что сам объект защиты устроен иначе, чем классический сервер или рабочая станция.

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

Образ как источник риска — уязвимость может попасть в систему ещё до первого запуска, если в базовом слое образа есть открытая CVE или в коде случайно закоммичен ключ доступа: это риск на этапе сборки, а не эксплуатации. Общее ядро в runtime — в отличие от виртуальных машин, контейнеры на одном хосте делят ядро операционной системы, поэтому побег из контейнера (container escape) — реальный класс атак, которого не существует для полноценной виртуализации.

Класс нужен организациям, у которых контейнеризация — не эксперимент, а рабочий процесс: несколько сервисов в проде, регулярные деплои через CI/CD, кластер Kubernetes или OpenShift под нагрузкой. Для одного тестового контейнера на разработческой машине специализированное решение обычно избыточно — достаточно базового сканирования образа перед публикацией. Список конкретных продуктов класса — на странице каталога «Безопасность контейнеров».

Жизненный цикл контейнера проходит три стадии, и на каждой нужен свой механизм контроля — продукт может закрывать одну стадию, несколько или все сразу, и это стоит уточнять отдельно, а не полагаться на общее название «container security» в описании вендора.

Ни одна стадия не заменяет другие: сканирование образа не остановит атаку на уже работающий под, а runtime-детект не подскажет разработчику про уязвимую библиотеку на этапе сборки. Для зрелого процесса нужны все три, пусть и не обязательно от одного вендора.

Ниже — на что стоит смотреть у любого кандидата независимо от вендора, сгруппировано по функции, а не по маркетинговому названию модуля.

1. Зафиксируйте стек: рантайм (Docker/containerd/CRI-O), оркестратор (Kubernetes, OpenShift или отечественная платформа) и их версии в проде.
2. Проверьте, закрывает ли кандидат все три стадии — сканирование образов, admission control, runtime-защиту — или только часть, и какие продукты нужны для остальных.
3. Оцените глубину сканирования образов: базовый слой, зависимости приложения, поиск секретов, а не только CVE в ОС.
4. Проверьте поддержку сканирования IaC и Kubernetes-манифестов до деплоя.
5. Уточните, можно ли настраивать собственные политики admission control и блокировать деплой, а не только логировать нарушение.
6. Проверьте совместимость с вашим реестром образов, включая изолированные и локальные зеркала.
7. Оцените нагрузку runtime-агента на производительность кластера под реальной, а не синтетической нагрузкой.
8. Проверьте готовую интеграцию с вашей CI/CD-системой — не только наличие API, а готовый плагин или шаг пайплайна.
9. Для КИИ и госсектора — сверьте статус сертификата ФСТЭК конкретного продукта в госреестре СЗИ ФСТЭК и запись в Реестре российского ПО.
10. Посчитайте TCO на 2–3 года: лицензия, встраивание в CI/CD, обучение команды, поддержка.
11. Запросите пилот на реальном кластере и реальных образах — синтетический демо-стенд вендора не покажет нагрузку и число ложных срабатываний вашей инфраструктуры.

• Закрывать только сканирование образов и считать вопрос решённым. Часть атак — эскалация привилегий, побег из контейнера, аномальный сетевой трафик — видна только в runtime; продукт без этой стадии закрывает лишь часть модели угроз.
• Встраивать сканирование в CI/CD без блокирующей политики. Отчёт об уязвимостях, который никто не читает после релиза, не снижает риск — сканирование должно уметь останавливать сборку при критической находке, а не просто фиксировать её.
• Ориентироваться только на Docker, игнорируя containerd и CRI-O. Часть кластеров Kubernetes уже работает без Docker Engine, и решение, которое проверяет только Docker-специфичные механизмы, может не увидеть часть контейнеров в кластере.
• Не проверять деградацию производительности от runtime-агента. Агент, который перехватывает системные вызовы, добавляет накладные расходы — под нагрузкой это может ощутимо повлиять на задержку приложения, и это стоит измерить до, а не после внедрения.
• Не закладывать в TCO обучение DevOps-команды. Решение внедряет обычно не отдел информационной безопасности в одиночку, а совместно с командой разработки — без их вовлечённости политики либо не применяются, либо блокируют легитимные деплои.

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

Смежные классы, которые часто рассматривают вместе с защитой контейнеров: WAF — защита самого приложения, которое работает внутри контейнера, на уровне HTTP-трафика, VM (управление уязвимостями) — более широкий процесс приоритизации CVE не только в образах, но и во всей инфраструктуре. Требования к безопасной разработке, которые касаются и контейнеризованных приложений, разобраны в разделе «РБПО и ГОСТ Р 56939-2024» на SecRadar.