Анатомия побега из контейнера: Техническое руководство по защите Runtime и Kubernetes

Анатомия побега из контейнера: Техническое руководство по защите Runtime и Kubernetes

В 2026 году ландшафт угроз для контейнерных сред окончательно сформировался. Мы больше не видим массовых атак, опирающихся исключительно на 0-day уязвимости в ядре Linux или коде контейнерных движков. Реальность Red Team операций и инцидентов в продакшене такова: изоляция контейнера заканчивается не на границе образа, а на границе ядра хоста и плоскости управления (Control Plane).

Большинство сценариев «побега» (Container Escape) начинается не с эксплуатации сложного бага в коде, а с ошибок конфигурации. Это привилегии, небезопасные маунты (mounts), доступ к сокетам рантайма, ошибки в RBAC и отсутствие контроля адмиссии (Admission Control) в Kubernetes.

Я часто наблюдаю, что команды фокусируются на сканировании образов на CVE, упуская из виду архитектурные риски. Red Team в первую очередь проверяет конфигурационные плоскости: Runtime, Kubernetes RBAC, доступ к секретам и внешним API. Эти векторы позволяют выстроить цепочку эскалации привилегий из контейнера до уровня Node или Cluster Admin без необходимости использовать редкие и нестабильные kernel-эксплойты.

Этот материал — руководство по внедрению защиты, основанное на реальной практике предотвращения побегов из контейнеров.

1. Граница изоляции: Мифы и Реальность

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

Контейнер vs Виртуализация

Контейнер использует общее с хостом ядро Linux. Его изоляция строится на базе механизмов ядра:

• Namespaces: изолируют вид ресурсов (PID, Network, Mount, UTS, IPC, User).
• Cgroups: ограничивают потребление ресурсов (CPU, RAM).
• LSM (Linux Security Modules): профили безопасности (AppArmor, SELinux) и фильтрация системных вызовов (seccomp).

Это не полноценная виртуализация железа и не отдельное ядро, как в случае с VM. Соответственно, любая возможность управлять структурами ядра (через capabilities, привилегированный режим, доступ к файлам устройств /dev/, cgroups или загрузку модулей ядра) автоматически становится кандидатом на «выход из контейнера».

Kubernetes добавляет поверх этого свой слой абстракции и риска: Kubernetes API, etcd, kubelet, CNI/CSI плагины, admission-контроллеры и RBAC. Компрометация этих компонентов часто дает злоумышленнику более простой и стабильный путь к захвату узла (node) или всего кластера, чем попытка эксплуатации багов ядра (kernel panic или memory corruption).

Сравнение моделей безопасности

С практической точки зрения граница изоляции — это сочетание: Linux-ядра на воркере (node) + политик безопасности Kubernetes (RBAC, Pod Security, admission, network policies), а не сам «образ контейнера».

АспектКонтейнерВиртуальная машина (VM)ЯдроОбщее с хостом ядро Linux. Единая точка отказа.Собственное ядро внутри гипервизора.Изоляция ресурсовNamespaces + cgroups + LSM (программная изоляция).ВМ-гипервизор, эмуляция виртуального железа (аппаратная поддержка).Эксплойт для обхода границыЧасто misconfig (privileged, docker[.]sock, hostPath, capabilities).Уязвимость в гипервизоре (VMM escape) или прошивке.Последствия capture одного rootВысокий риск выхода на node/cluster при малейшем misconfig.Обычно ограничено рамками конкретной ВМ, гипервизор остается отдельным слоем.

Практика последних лет однозначно показывает: успешные container escape-кейсы чаще опираются на комбинации привилегий и маунтов, чем на чистую эксплуатацию CVE в ядре.

Важно: В отчетах Red Team и Threat Intel злоумышленники штатно используют docker[.]sock, hostPath, режимы hostPID/hostNetwork и чрезмерный набор capabilities для выхода к файловой системе и устройствам узла.

2. Типовая модель угроз для контейнеров (2026)

Для построения защиты мы должны мыслить как атакующий. Модель угроз в Kubernetes-среде описывается следующим образом.

Начальная точка (Initial Access)

Атака начинается с захвата контекста исполнения внутри контейнера. Это может произойти через:

• RCE (Remote Code Execution) в уязвимом веб-приложении или API.
• Украденный токен CI/CD, позволяющий задеплоить вредоносный образ или изменить конфигурацию.
• Компрометация рабочего места разработчика, дающая доступ к консоли контейнера (kubectl exec).

Цель (Objectives)

Основная цель атакующего — повышение привилегий до root на node (container escape). Достигнув уровня узла, атакующий стремится к административному контролю над всем кластером, Kubernetes API или облачной инфраструктурой (AWS/GCP/Azure через метаданные).

Ключевые оси эскалации

1. Горизонтальное движение (Lateral Movement)

Движение внутри кластера без выхода на хост.

• Использование сервис-аккаунтов (Service Accounts) с неоправданно широкими правами.
• Использование прав ClusterRole или cluster-admin.
• Отсутствие сетевых политик (Network Policies), позволяющее обращаться к внутренним сервисам.

2. Вертикальная эскалация (Privilege Escalation)

Выход из контейнера на уровень операционной системы узла.

• Привилегированный контейнер (privileged: true).
• Доступ к сокетам рантайма (docker[.]sock, containerd[.]sock).
• Опасные маунты hostPath.
• Прямой доступ к /dev/ и интерфейсам ядра.

В этой модели 90% риска задается конфигурацией Kubernetes/runtime и только оставшаяся часть — уязвимостями нулевого дня в ядре или контейнерном движке.

3. Конфигурационные векторы “Escape-Risk”: Глубокий анализ

Ниже представлен детальный разбор набора типичных мис-конфигураций, которые гарантированно приводят к «выходу из контейнера». Это не теоретические уязвимости, а стандартные настройки, которые часто оставляют включенными для удобства отладки или из-за непонимания последствий.

Основные векторы компрометации:

• Привилегированные контейнеры (docker run --privileged / privileged: true в PodSpec).
• Широкие capabilities (особенно CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE, CAP_NET_ADMIN).
• Маунты hostPath и доступ к файловой системе node (/, /etc/, /var/ run/, /var/ lib/ kubelet, /run/ containerd).
• Маунт unix-сокетов (docker[.]sock/containerd[.]sock/cri-socket) внутрь контейнера.
• Режимы hostPID/hostIPC/hostNetwork, дающие доступ к пространствам имен node.
• Отключенные/ослабленные профили seccomp/AppArmor/SELinux.
• Чрезмерные права в Kubernetes RBAC (cluster-admin для SA приложений, Role/ClusterRole с * по verb/resource).
• Отсутствие Admission-контроля, ограничивающего создание небезопасных Pod’ов.

Все крупные гайды по Kubernetes-hardening (NSA/CISA, CNCF, вендорские best practices) прямо рекомендуют применять стратегию default-deny для привилегий, маунтов и доступов к API.

Детальный разбор: Привилегированные контейнеры и Capabilities

Включение флага --privileged (или securityContext.privileged: true в Kubernetes) — это фактически выключение механизмов безопасности контейнера.

Технические последствия --privileged

При таком запуске контейнер получает:

• Полный набор всех Linux-capabilities.
• Доступ ко всем устройствам в /dev/ хоста.
• Обход профилей AppArmor/SELinux и фильтров seccomp.
• Возможность монтирования файловых систем.

Исследования и кейсы пентестов показывают: при наличии такого контейнера злоумышленнику достаточно выполнить несколько операций с устройствами или модулями ядра, чтобы получить root-доступ на хосте.

Опасность отдельных Capabilities

Даже без полного флага --privileged, ручное добавление определенных capabilities может открыть путь к побегу.

• CAP_SYS_ADMIN: Часто называют «god capability». Она перегружена функционалом. Позволяет управлять монтированием (mount), пространствами имен (namespaces), cgroups, файлами подкачки и выполнять ряд чувствительных ioctl. Это практически эквивалент root на хосте.
• CAP_SYS_MODULE: Позволяет загружать и выгружать модули ядра (kernel modules). Злоумышленник может загрузить руткит прямо в ядро хоста из контейнера.
• CAP_SYS_PTRACE: Позволяет отлаживать и модифицировать процессы. В сочетании с hostPID позволяет внедриться в процесс, запущенный на хосте (например, sshd или kubelet).
• CAP_NET_ADMIN: Позволяет изменять сетевые настройки, таблицы маршрутизации, интерфейсы и правила iptables на узле (особенно критично при наличии hostNetwork).

Рекомендация: Следуйте гайду NSA/CISA — запускайте контейнеры с минимальным набором привилегий, используйте drop: ["ALL"] и добавляйте только необходимые capabilities (add: ["NET_BIND_SERVICE"]), и по возможности работайте как non-root.

Детальный разбор: HostPath и сокеты контейнерного рантайма

Монтирование директорий с хоста (hostPath) внутрь контейнера пробивает дыру в изоляции файловой системы. Если при этом процесс внутри контейнера работает от root, он может модифицировать файлы хоста.

Типичные сценарии атаки через HostPath

• Маунт корня / (или /etc/, /var/, /root/):
  Злоумышленник получает полный доступ к файловой системе узла. Он может:Добавить свой SSH-ключ в /root/ .ssh/ authorized_keys.
  Изменить /etc/ shadow или /etc/ passwd.
  Подменить бинарные файлы системы или конфигурацию systemd-юнитов для закрепления.
  Использовать технику chroot /host-fs, чтобы "стать" частью хоста.
  
• Маунт сокетов /var/ run/ docker[.]sock, /run/ containerd/ containerd[.]sock, /var/ lib/ kubelet:
  Это один из самых критичных векторов. Имея доступ к сокету Docker или Containerd, процесс внутри контейнера может отправлять API-команды демону, управляющему контейнерами.Сценарий: Злоумышленник отправляет команду на запуск нового контейнера с флагом --privileged, монтирует в него корень хоста (-v /:/mnt) и выполняет в нем шелл.
  Результат: Полный контроль над узлом, обходя все ограничения исходного скомпрометированного контейнера.
  

Кейсы из отчетов Unit42 и Red Canary подтверждают: это самый «практичный» и часто встречающийся путь container escape в продакшн-окружениях.

Детальный разбор: HostPID, HostNetwork, HostIPC

Разрешение использования пространств имен хоста в PodSpec (hostPID: true, hostIPC: true, hostNetwork: true) размывает границы изоляции.

• hostPID: true: Контейнер видит все процессы на узле, а не только свои. Это упрощает доступ к чувствительной информации (чтение /proc/ <pid>/ environ процессов хоста, где могут быть пароли) и межпроцессному взаимодействию. При наличии прав (capabilities) возможен инжект кода.
• hostNetwork: true: Контейнер использует сетевой стек хоста. Он может перехватывать трафик (sniffing) всех подов на узле, обращаться к сервисам, слушающим на localhost хоста (часто это незащищенные админские интерфейсы или облачные метаданные), и манипулировать сетевыми интерфейсами.
• hostIPC: true: Доступ к объектам межпроцессного взаимодействия (Shared Memory) хоста.

Pod Security Standards и встроенный контроллер Pod Security Admission прямо относят эти настройки к категории повышенного риска и требуют их запрета в профиле restricted. Документация Kubernetes подчеркивает: такие настройки допустимы только для строго контролируемых системных DaemonSet’ов (например, CNI-плагинов или агентов мониторинга), но никогда — для прикладных приложений.

4. Kubernetes API и RBAC: Путь к господству в кластере

Даже если контейнер идеально изолирован на уровне ядра Linux (нет привилегий, нет маунтов), он может содержать токен сервис-аккаунта (Service Account Token), смонтированный по умолчанию в /var/ run/ secrets/ kubernetes.io/ serviceaccount.

Если этому ServiceAccount выданы чрезмерные права через RBAC, атакующий может эскалировать свои привилегии через API Kubernetes.

Продолжение на сайте redsec.by >>>