Какие основные угрозы безопасности контейнеров существуют?

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

Представьте контейнер как квартиру в многоэтажном доме. Угрозы могут исходить от соседей (другие контейнеры на том же хосте), от поставщиков мебели (зависимости и базовые образы), от незапертых дверей (неправильная конфигурация) и от самого жильца (запущенный процесс).

Угрозы на уровне образов

• Уязвимости в базовых образах – устаревшие пакеты и библиотеки с известными CVE (Common Vulnerabilities and Exposures). Каждый непропатченный пакет – потенциальная точка входа для атакующего.
• Вредоносные образы – использование непроверенных образов из публичных реестров (Docker Hub) может привести к внедрению троянов или бэкдоров.
• Утечка секретов – пароли, ключи API, сертификаты, случайно включённые в слои образа. Даже если секрет удалён в последующем слое, он остаётся доступен через docker history.
• Избыточные компоненты – лишние утилиты и инструменты (curl, wget, bash) увеличивают поверхность атаки, предоставляя атакующему инструментарий для дальнейшего проникновения.

Угрозы на уровне среды выполнения (runtime)

• Побег из контейнера (container escape) – эксплуатация уязвимостей ядра Linux для получения доступа к хост-системе. Контейнеры разделяют ядро с хостом, что делает этот вектор особенно опасным.
• Запуск от root – контейнер с правами root (UID 0) при побеге даёт атакующему root-доступ на хосте.
• Привилегированный режим – флаг --privileged даёт контейнеру полный доступ к устройствам хоста, фактически снимая изоляцию.
• Незащищённый Docker socket – доступ к /var/run/docker.sock позволяет управлять всеми контейнерами на хосте, включая создание новых привилегированных контейнеров.

Угрозы на уровне оркестрации (Kubernetes)

• Неправильная настройка RBAC – избыточные права для сервисных аккаунтов позволяют скомпрометированному поду получить контроль над кластером.
• Отсутствие сетевых политик – по умолчанию любой под может обращаться к любому другому поду в кластере, что облегчает боковое перемещение (lateral movement).
• Незащищённый API-сервер – открытый доступ к Kubernetes API без аутентификации позволяет любому управлять кластером.
• Компрометация etcd – хранилище всех данных кластера, включая секреты в открытом виде (если не настроено шифрование at rest).

Угрозы на уровне цепочки поставок (supply chain)

• Подмена зависимостей (dependency confusion) – вредоносные пакеты с именами, совпадающими с внутренними библиотеками организации.
• Компрометация CI/CD – внедрение вредоносного кода через пайплайн сборки (например, подмена шагов в Jenkinsfile или GitHub Actions).
• Отсутствие проверки целостности – использование образов без верификации подписи не гарантирует, что образ не был подменён.

Угрозы на уровне сети

• Man-in-the-middle – перехват трафика между контейнерами при отсутствии mTLS.
• Незашифрованный трафик – передача данных без TLS внутри кластера позволяет перехватить чувствительную информацию.
• Эксфильтрация данных – несанкционированная отправка данных наружу через незаблокированный egress-трафик.

Вывод

Для банковских систем особенно критичны: утечка персональных данных (ФЗ-152), утечка платёжных данных (PCI DSS), несанкционированный доступ к финансовым транзакциям. Эшелонированная защита (defense in depth) предполагает применение мер на каждом уровне одновременно.

На собеседовании: обычно ожидают, что кандидат перечислит хотя бы 3-4 категории угроз и приведёт конкретные примеры. Упомяните container escape, запуск от root, утечку секретов в образе и отсутствие Network Policies – это покажет понимание разных уровней атаки.