Статья Kubernetes security 2025: что изменили новые уязвимости в runc и контейнерах

Kubernetes‑кластеры в 2025‑м живут в другом мире, чем три‑четыре года назад. runc перестал быть «прозрачной» деталью под капотом Docker и k8s: новые уязвимости показали, что сам контейнерный рантайм стал полноценной зоной боевых действий, а не просто инфраструктурным фоном. Эта статья - попытка переосмыслить модель угроз Kubernetes и контейнеров после свежих CVE и собрать практический чек‑лист для тех, кто отвечает за безопасность прод‑кластеров.

Когда изолирующий слой сам становится целью​

2025 год принёс целую серию контейнерных побегов - уязвимостей, позволяющих выскочить из контейнера на хост и дальше в плоскость управления кластера. В центре внимания оказались новые баги в runc: CVE‑2025‑31133, CVE‑2025‑52565 и CVE‑2025‑52881. Они эксплуатируют ошибки в обработке maskedPaths, работе с /dev/console и монтировании /proc, что даёт возможность обходить ограничения неймспейсов и записывать данные в чувствительные системные файлы хоста.

Если раньше в типичном докладе про безопасность Kubernetes раздел «контейнерный рантайм» занимал один‑два слайда, то теперь этого явно недостаточно. runc, crun и их аналоги стали тем самым «пограничным контролем», от которого зависит, останется ли компрометация на уровне пода или пойдёт вверх по всей инфраструктуре.

Что изменили новые CVE в модели угроз​

Классическая учебная картинка выглядела так: приложение → контейнер → хостовое Linux‑ядро → управляющая плоскость Kubernetes. runc фигурировал где‑то между контейнером и ядром и считался достаточно надёжным, чтобы про него не думать. Новые CVE ломают это допущение сразу в нескольких местах.

• CVE‑2025‑31133 и CVE‑2025‑52565 эксплуатируют гонки и ошибки проверки в механизмах maskedPaths и монтировании /dev/console: через подмену /dev/null на симлинк или манипуляции монтированием можно добиться записи в чувствительные /proc‑пути хоста и обойти защиту LSM.
• CVE‑2025‑52881 дополняет картину возможностью переадресовать записи runc в произвольные файлы /proc, фактически получая готовые «гаджеты» для повышения привилегий на хосте.

Вывод простой и неприятный: граница «контейнер ↔ хост» стала куда хрупче, чем казалось, а безопасность кластера больше не может опираться только на утверждение «контейнеры шарят одно ядро, но изолированы неймспейсами».

Чтобы глубже понять, как новые уязвимости встраиваются в общую картину угроз для контейнерных сред, рекомендуем ознакомиться со статьей «Матрица угроз для Kubernetes: понимание и защита контейнерных сред» - в нём систематизированы векторы атак на разных уровнях архитектуры k8s.

Контейнерное бегство как стандартный сценарий атак​

Отчёты за 2025 год показывают: большая часть продакшн‑образов содержит минимум один high/critical CVE, а число новых уязвимостей продолжает расти. В такой среде container escape перестаёт быть экзотикой и становится ожидаемой стадией сложной атаки.
Типовой сценарий выглядит так:

1. Компрометация приложения внутри пода (RCE, уязвимая библиотека, баг в бизнес‑логике).
2. Эксплуатация ошибки рантайма или ядра (свежая runc‑CVE, уязвимость в файловой системе, eBPF‑баг) для выхода на хост.
3. Дальнейшее движение в сторону kubelet и kube‑api: кража токена сервис‑аккаунта, доступ к /var/lib/kubelet и credential‑файлам.
4. Перехват управления над нодой и затем над управляющей плоскостью.

Контейнер перестаёт быть «песочницей», а становится лишь первым шагом в цепочке. Это сдвигает и приоритеты защитных мер: одних policy в Kubernetes уже недостаточно, нужно думать об изоляции на уровне самого рантайма и ядра.

Как новые уязвимости бьют по Docker и Kubernetes​

Многие команды по инерции воспринимают Docker как локальную сборочную утилиту, а Kubernetes - как «настоящую» боевую среду. Новые баги в runc бьют по этому разделению: сама фаза сборки образа становится площадкой атаки, если build‑агенты используют уязвимые версии рантайма и ядра.

• Компрометация CI‑агента через runc‑эксплойт ведёт к компрометации registry и всех деплойментов, то есть к масштабному supply‑chain‑инциденту.
• Ошибки конфигурации (привилегированные build‑контейнеры, доступ к сокету Docker‑демона) усиливают эффект: успешный побег даёт злоумышленнику root‑доступ ко всей инфраструктуре сборки.

Практический вывод: hardening нужен не только runtime‑нодам, но и билд‑инфраструктуре - GitLab Runner, self‑hosted GitHub Actions, Jenkins‑агентам и т.п.

Kubernetes: уязвимость рантайма = уязвимость ноды​

В Kubernetes рантайм - часть доверенной базы. kubelet опирается на CRI‑адаптер (containerd, CRI‑O), который внутри использует тот же runc. Любая уязвимость runc автоматически превращается в уязвимость всех подов, работающих на ноде.

Последствия:

• Привилегированные поды и поды с hostPID, hostNetwork, широкими hostPath‑монтами становятся критическими: если атакующий выбрался из такого контейнера, у него почти нет ограничений на хосте.
• Токены сервис‑аккаунтов в файловой системе пода превращаются в прямой путь к управляющей плоскости: достаточно сбежать из контейнера и прочитать их в смонтированных секретах или через директории kubelet.
• Node‑local службы (агенты мониторинга, логгеры, security‑sidecar’ы) часто работают с повышенными привилегиями; выход к ним через контейнерное бегство даёт быстрый путь к латеральному перемещению как внутри кластера, так и за его пределами.

По сути любая нода с уязвимым runc - это потенциальный бэкдор в control plane, особенно если на ней живёт хотя бы один контейнер с избыточными правами.

Практика обновлений и hardening​

Первый слой обороны банален, но критичен: нужно убедиться, что на всех нодах используются версии runc и контейнерного движка, закрывающие свежие CVE 2025 года, и что сама ОС получает регулярные обновления ядра. Многие вендоры (дистрибутивы Linux, GKE/EKS/AKS) публикуют отдельные бюллетени по этим уязвимостям - их нужно читать не «когда‑нибудь», а в день выхода.

При этом бездумный автоапдейт по cron’у - почти гарантированная боль. Для прод‑кластеров разумно:

• держать staging‑кластер, куда первыми выкатываются обновления хоста и рантайма;
• использовать PodDisruptionBudget и аккуратно выводить ноды в cordon/drain, чтобы обновления не приводили к одновременному падению нескольких критичных подов;
• иметь задокументированную процедуру rollback’а версии ядра или образа ноды.

Если вы строите микросервисную архитектуру на Kubernetes и хотите изначально закладывать принципы безопасности в design приложений, обратите внимание на книгу «Kubernetes Native Microservices: With Quarkus and MicroProfile»

Минимизировать привилегии контейнеров​

Новые runc‑CVE особенно опасны, когда из контейнера уже есть куда «выскочить». Чем меньше прав дано на хосте, тем короче траектория атаки и тем больше шансов, что побег упрётся в дополнительный барьер.
Хорошая база для манифестов:

• securityContext.runAsNonRoot: true и явный runAsUser, чтобы root внутри контейнера не совпадал с root на хосте.
• allowPrivilegeEscalation: false, запрет privileged: true, отказ от hostPID, hostIPC, hostNetwork, если без них можно обойтись.
• readOnlyRootFilesystem: true для большинства сервисов: это усложняет запись в системные пути, которые эксплойты часто используют как «точки опоры».
• Агрессивный capabilities.drop: ["ALL"] и точечное добавление только необходимых capability.

Даже если эксплойт сработает, такой под будет значительно менее удобной отправной точкой для дальнейшего движения.

Пересмотр политики образов и CI​

Часть атак смещается в сторону фазы сборки и распространения образов, поэтому к Dockerfile и CI‑pipeline нужно относиться как к полноценному коду, а не техническому шуму.
Практические шаги:

• добавить статический анализ Dockerfile и образов (Trivy, Grype, Snyk, Anchore и др.) в CI и падать по критичным CVE ещё до деплоя;
• перейти на минимальные и distroless‑образы, где меньше потенциальных точек атаки и заметно ниже общий CVE‑футпринт;
• жёстко ограничить использование публичных реестров: прод‑кластеры должны тянуть образы только из доверенного private registry, а использование imagePullPolicy: Always и плавающих тегов :latest - это приглашение к сюрпризам;
• ввести код‑ревью для Dockerfile с чек‑листом: отсутствие лишних пакетов, отсутствие curl | sh из непроверенных источников, отсутствие постоянного монтирования сокетов Docker‑демона.

Defensive‑практики для Blue Team: мониторинг и реагирование​

После всплеска уязвимостей в runc привычный список «аномалий в логах приложений» уже не хватает. Нужны сигналы, которые отражают именно попытку побега или работы с хостом.
Стоит обратить внимание на:

• неожиданные обращения контейнеров к чувствительным путям /proc и системным файлам, не используемым штатным кодом;
• создание или изменение файлов в директориях, смонтированных как hostPath, вне заранее утверждённого списка;
• появление в контейнере утилит, которых не должно быть в образе: интерактивные шеллы, сетевые сканеры, отладчики;
• резкую смену сетевой активности пода - появление прямых запросов к kube‑api, обращений к метаданным cloud‑провайдера и нетипичных внешних IP;
• изменение конфигурации системных служб на ноде (kubelet, агенты мониторинга) вскоре после аномальной активности в одном из подов.

Какой стек инструментов достаточно зрелый для 2025 года​

Полный набор из десятка агентов и SaaS‑платформ необязателен. Для команды уровня Middle можно собрать разумный минимум.

• Средства проверки конфигурации по CIS Benchmark и другим гайдам (kube‑bench, Kubescape, специализированные аудит‑операторы).
• eBPF‑ и rule‑based сенсоры вроде Falco или Tracee для отслеживания системных вызовов, подозрительных монтирований и изменений в файловой системе.
• Runtime‑сканеры образов в кластере (оператор Trivy, решения от Aqua, Wiz, других вендоров) для отслеживания новых критичных CVE в уже запущенных подах.
• Включённый Kubernetes Audit Log с экспортом в центральное хранилище и связкой с SIEM, чтобы расследования не упирались в отсутствие журналов.

Ключевой момент - не просто собирать алерты, а завести процедуры реагирования: что делать, если сенсор сообщил о попытке записи в /proc, о запуске sh внутри контейнера приложения или о появлении ранее неиспользовавшегося образа.

Заключение: жить с тем, что контейнеры не волшебная песочница​

Уязвимости runc 2025 года окончательно добили миф о том, что «контейнер = изоляция по умолчанию». На практике это лишь тонкий программный слой над общим ядром, который ошибается так же часто, как и любой другой сложный компонент. Разница только в том, что ошибка здесь автоматически поднимает уровень риска со «скомпрометированного микросервиса» до «скомпрометированной ноды и, возможно, всего кластера».
Обновлённый взгляд на безопасность Kubernetes в 2025 году опирается на три основные идеи.

1. Патчить рантайм и ядро так же дисциплинированно, как приложения. Уязвимости уровня runc - это не инфраструктурный шум, а прямые векторы к захвату кластера. Обновления нод, staging‑кластер и понятный rollback - обязательная гигиена.
2. Минимизировать последствия побега. Ограничение привилегий контейнеров, отказ от лишних host*‑опций, минимальные образы и аккуратное обращение с hostPath делают даже успешный побег менее разрушительным.
3. Смотреть на Kubernetes как на живую, наблюдаемую систему. Мониторинг системных вызовов, аудит конфигурации, инвентаризация образов и логирование действий в управляющей плоскости превращают «магический» оркестратор в понятную инженерную систему, в которой можно замечать и останавливать атаки.

Контейнеры и Kubernetes остаются мощным ускорителем разработки. Просто теперь к списку «плюсов» нужно добавить ещё один пункт: «требует взрослого отношения к безопасности рантайма».