k8s (in)security

Недавно мы задались вопросом: Сколько CVE из официального Kubernetes feeds можно закрыть политиками PolicyEngine (Kyverno/Gatekeeper)? И после нехитрого исследования получили следующие цифры. 1. Митигируется политиками (32 CVE) 1.1. Инъекции конфигурации ingress-nginx через объект Ingress (16 CVE) 1.2. Вектор — поля Pod/PV/Service/EndpointSlice спеки (16 CVE) 2. Частично митигируется (21 CVE) Политика снижает вероятность/последствия, но не закрывает уязвимость: либо режет только часть векторов, либо требует хрупкой кастомной эвристики, либо «лечит» ценой отключения легитимной функциональности. 3. Не митигируется admission-политиками (38 CVE) 3.1. Баг в обработке запроса apiserver — срабатывает до/вне admission (8 CVE) 3.2. Протокольные/сетевые баги kubelet, kube-proxy, apiserver-прокси (7 CVE) 3.3. Уязвим сам admission-вебхук ingress-nginx (3 CVE) 3.4. Утечки секретов/токенов в логи control-plane (6 CVE) 3.5. Клиентские инструменты и библиотеки (4 CVE) 3.6. Инфраструктура вне кластера: Image Builder, ОС нод, сторонние UI (6 CVE) 3.7. Поведение рантайма/контроллеров, не выражаемое в admission-объектах (4 CVE) PolicyEngine — не патч-менеджмент, а срез одного слоя. Но этот слой закрывает треть фида «малой кровью». Остальное — только обновления, RBAC, NetworkPolicy и контроль логов.

Kelos - AI-агенты как нативные ресурсы Kubernetes Все привыкли запускать кодинг-агентов локально: открыл терминал, набрал claude или codex, посидел рядом, посмотрел. Проект Kelos предлагает другой взгляд: а что, если агенты — это не одноразовые локальные команды, а декларативные ресурсы в кластере, как Deployment или CronJob? Kelos добавляет в K8s набор CRD, которые превращают работу AI-агентов в часть control plane: - Task — одиночный запуск агента с промптом (выполняется в эфемерном поде); - Session — долгоживущий диалог на StatefulSet, к которому можно подключаться из веба или терминала; - TaskSpawner — автоматическое порождение задач из GitHub Issues и PR, вебхуков, Jira или по расписанию; - Workspace — описание git-репозитория с аутентификацией; - AgentConfig — переиспользуемые наборы инструкций, плагинов и MCP-серверов. Под капотом поддерживаются Claude Code, OpenAI Codex, Gemini, OpenCode, Cursor и произвольные контейнерные образы. Задачи можно связывать в цепочки через dependsOn с передачей результатов между этапами — получается полноценная оркестрация: один агент скаффолдит сервис, второй пишет тесты, третий готовит PR. Что это даёт на практике: 1. GitOps для агентов. Промпты, конфигурации и workflow версионируются в git и раскатываются через kubectl/Helm — как любая другая инфраструктура. 2. Изоляция. Каждый агент живёт в своём поде без доступа к хосту и соседям, с RBAC, лимитами maxConcurrency и activeDeadlineSeconds. 3. Автономные пайплайны. Классический пример из README: TaskSpawner ловит issues с меткой bug и автоматически поднимает агента на исправление.

Awesome Docker Sandboxes — курируемая подборка ресурсов для запуска AI-агентов в Docker Sandboxes (sbx), о котором мы недавно уже писали. Это CLI-инструмент, который запускает AI-кодинг-агентов (Claude Code, Copilot, Gemini, OpenCode и др.) внутри изолированных microVM: с собственным ядром, Docker-демоном и сетевым стеком. Агент получает полную свободу действий, но не может навредить хост-системе. Репозиторий awesome-docker-sbx собирает всё, что появляется вокруг этой технологии: - официальные доки и квикстарты - обёртки, CLI и декларативные YAML-киты - шаблоны и базовые образы окружений - GUI и дашборды для управления песочницами - разборы модели угроз и security-демо Интересная деталь: список пополняется автоматически — Docker-агент по расписанию в GitHub Actions ищет новые репозитории и статьи про sbx, проверяет их на релевантность и предлагает в очередь на ручную модерацию. Проект молодой, но тема запуска автономных AI-агентов без риска для машины сейчас одна из самых горячих — стоит добавить в закладки.

Несправедливо мало внимания оказано шикарной уязвимости Januscape/CVE-2026-53359. - Guest-to-Host Escape в KVM/x86 - Уязвимости 16 лет ( с 2.6.39) - Уязвимы Intel и AMD (благодаря уязвимости в общем коде подсистемы ShadowMMU) - Класс уязвимости `use-after-free - Исправление вышло 19 июня - Уязвимы версии ядра Linux до: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260 - Для операторов виртуализации это риск компрометации всех VM на хосте - Не первый известный guest-to-host эксплоит для KVM, но первый который одновременно работает на Intel и AMD - Большинство старых и «привычных» уязвимостей класса VM Escape происходили не в самом KVM, а в QEMU - Нашел исследователь Хенву Ким (Hyunwoo Kim), получив за нее премию в $250 000 от Google в рамках программы kvmCTF - Для митигейшена рекомендуют отключить функцию вложенной виртуализации (Nested Virtualization) на хосте Подробнее: отчет исследователя, пост на openwall, NVD

Стала доступна запись эфира "Как развитие контейнеров влияет на информационную безопасность", где мы (Luntry) с коллегами из K2 вопросы специфики безопасности контейнерных окружений! Эфир получился очень интересным и задорным (особенно его вторая половина) - рекомендуем всем к ознакомлению ;)

Марафон LPE уязвимостей в Linux продолжается. Команда Nebula Security раскрыла GhostLock (CVE-2026-43499), stack-use-after-free в подсистеме rtmutex ядра, который был внесён ещё в Linux 2.6.39 и просуществовал более 15 лет. Корень бага в том, что на proxy-пути функция remove_waiter() очищает pi_blocked_on не у той задачи, оставляя висячий указатель на освобождённый фрейм стека ядра. Затронуты практически все дистрибутивы без патча (диапазон от v2.6.39-rc1 до v7.1-rc1), причём триггер не требует ни привилегий, ни user namespaces, ни специальной конфигурации ядра. Ключевая опасность в том, что уязвимость превращается в container escape, локальный непривилегированный атакующий из контейнера может подняться до root на хосте. Авторы довели эксплойт до 97% стабильности через forge поддельного rt_mutex_waiter, перезапись inet6_protos[IPPROTO_UDP] и трюк с CPU entry area, за что получили 92 337 долларов в Google kernelCTF. Полностью рабочий эксплойт и PoC уже открыто выложены в репозитории CyberMeowfia на GitHub.

О том, что NIST не справляется с наплывом уязвимостей и меняет свой подход по работе с CVE думаю видели и читали все. Почти с аналогичным посылом в своем блоге выступила и команда GitHub в посте "Inside the Advisory Database and what happens when vulnerability volume breaks records". Что и как делать в таких реалиях мы рассказывали в рамках доклада «Уязвимости в контейнерах и Kubernetes: правим, а не страдаем» c CISO ФОРУМ 2026.

Исследователь под ником bikini опубликовал на GitHub целый набор из 23 эксплойтов для популярных проектов, включая FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2 и 7-Zip. Часть уязвимостей относится к категории 0-day, а сам код был создан с помощью fuzzing-инструментов в связке с AI-моделью. Отдельно хотим отметить уязвимость в Docker. Команда docker cp при копировании файлов из контейнера на хост может обрабатывать символические ссылки таким образом, что позволяет вырваться за пределы указанного каталога и записать данные в произвольное место на хост-системе. То есть недоверенный контейнер потенциально способен перезаписать чужие файлы на машине, где выполняется копирование. CVE идентификаторы для большинства находок пока не назначены, а публикация рабочих эксплойтов до исправления вызвала споры в сообществе о допустимости такого раскрытия.

Возможно вы помните как мы писали, что рабочая группа в рамках Kubernetes работала и успешно разработала новые типы сетевых политик. И что к NetworkPolicy присоединились еще BaselineAdminNetworkPolicy и AdminNetworkPolicy. Кто-нибудь работал с ними?! А если нет, то теперь и не поработаете, так как им на смену сделали ClusterNetworkPolicy =) Обо всех этих хитросплетениях можно подробнее узнать из статьи "API update for v1alpha2: ClusterNetworkPolicy replaces AdminNetworkPolicy and BaselineAdminNetworkPolicy" и на странице Network Policy API Working Group. P.S. На последней странице еще угрожающе маячит "DeveloperNetworkPolicy - Possible APIs to be created in the future" ...

Исследователи из Synacktiv обнаружили неаутентифицированную RCE в компоненте repo-server Argo CD. Уязвимость нашли с помощью CodeQL: стандартные проверки ничего не давали, поэтому исследователи написали собственный model pack, помечающий второй параметр API-методов как источник недоверенных данных, и вышли на command injection в обработке kustomize. Суть эксплуатации в том, что gRPC-сервер repo-server не требует аутентификации, а через поле KustomizeOptions можно подсунуть параметры --enable-helm --helm-command, чтобы выполнить произвольную команду и, например, украсть пароль от Redis. Дальше через незащищённый Redis подменяются кэшированные манифесты и git-refs, что при включённом Auto Sync приводит к развёртыванию вредоносного манифеста и полному захвату кластера — причём без опции selfHeal, в отличие от прежней находки Cycode. Уязвимость зарепортили мейнтейнерам ещё в январе 2025 года, но она до сих пор не исправлена. Сетевые политики, поставялемые в инсталяции Argo CD защитили бы от атаки, но при установке через Helm они по умолчанию не применяются. P.S – для эксплуатации необходимо использовать часть библиотек Argo CD. Нам удалось успешно воспроизвести уязвимость.