Microsoft также не проходит мимо темы изоляции/ограничения AI-агентов.

Microsoft eXecution Container (MXC) — это SDK (Rust, .NET и Node.js) для запуска не доверенного кода в песочнице с явно заданными правами в Windows, Linux, macOS.

MXC позволяет приложению задать границы выполнения:
- Файлы: какие пути доступны только для чтения, какие — для записи, а какие запрещены.
- Сеть: ограничения исходящих соединений, настройки прокси и, в зависимости от backend, фильтрация хостов.
- Интерфейс: ограничения доступа к буферу обмена, дисплею и GU`I — там, где `backend это поддерживает.
- Выполнение: запуск команд и управление жизненным циклом изолированной среды.

И пусть вас не путает слово Container в названии (как нас сначала)! Это не имеет ничего общего с OCI образами и нашими любимыми контейнерами). Для каждой ОС тут свой backend изоляции:
- Windows — уровень BaseContainer backend ProcessContainer;
- macOS — Seatbelt;
- Linux — Bubblewrap.

Приложение передаёт команду, тип среды и политику доступа, а MXC проверяет запрос и запускает нагрузку через выбранный механизм изоляции.

В прошлом году мы уже рассказывали про Zeroday Cloud от WIZ. В этом году мероприятие повторяется.

Скоуп и расценки расширяются. Так например, за успешный эксплойт в gVisor или Firecracker у исследователей есть шанс получить $200,000, а в NGINX – $300,000.

Результаты будут представлены в лайве на Black Hat Europe 9-10 декабря. Выплаты в этом ивенте существенно выше, по сравнению с существующим расценками в багбаунти для этих продуктов.

kern — rootless-контейнерный runtime без постоянного демона. Запускает OCI-образы, предлагает Python/Node SDK и MCP для выполнения кода AI-агентов.

kern это не другой способ изоляции вместо контейнеров. Это тоже Linux-контейнеры, но с другой архитектурой runtime, настройками безопасности и интерфейсами для разработчика. Большинство соответствующих ограничений можно организовать и в Docker/Podman. Разница — в том, насколько готовым и удобным получается этот сценарий без собственной обвязки.

Но самое интересное в проекте (по крайней мере для нас) — три документа: SECURITY.md, THREAT_MODEL.md и CVE-POSTURE.md. Эти документs честно и прямолинейно отвечают на вопросы: что именно защищает песочница и где защита заканчивается?

На пример, в CVE-POSTURE описывается 25 способов побега из контейнера и как с этим справляется данный проект. А так как проект базируется на классических механизмах контейнеризации (а не microVM, sandbox и т.д.), то это все очень просто перенести для понимания картины в классических контейнерах Docker/Podman.

В общем, как минимум для образовательных целей репозиторий прям очень полезен.

В своей статье Kubernetes Ingress vs Gateway API Isovalent сравнивает Kubernetes Ingress и Gateway API — два подхода к маршрутизации трафика внутри кластера. Ingress подходит для базовой маршрутизации HTTP/HTTPS, но при усложнении инфраструктуры его возможностей и гибкости может не хватать.

Gateway API предлагает более расширяемую модель с разделением ответственности между инфраструктурными и прикладными командами. Он поддерживает сложные правила маршрутизации и позволяет обходиться без привязки к специфичным аннотациям отдельных контроллеров.

Gateway API — перспективный выбор для новых Kubernetes кластеров и сложных сценариев маршрутизации, тогда как Ingress остаётся рабочим вариантом для простых конфигураций.

На днях была опубликована громкая уязвимость CVE-2026-99999 (PwnEscape), которая позволяет побег из гостевой VM на хост.

А что относительно классических Linux контейнеров?

Из состояния на сегодня:
- публичных материалов на этот счет нет
- так как уязвимость в IPv4-стеке ядра Linux, а не непосредственно в KVM, то потенциал есть
- есть возможность локального запуска атаки, а не только из VM
- недостаточно просто отправить специально сформированный IP-пакет, также требуется контроль над метаданными отложенного вычисления контрольной суммы, которые затем обрабатывает ядро. В подтверждённом сценарии VM эти данные поступают через virtio-net и сетевой путь хоста. У обычного контейнера путь другой.
- для контейнера также важно - доступны ли нужные сетевые интерфейсы и операции с учётом capabilities, namespaces, seccomp и LSM

Как итог: PwnEscape — подтверждённый VM escape и пока потенциальный риск для контейнерной изоляции.

В ядре Linux развивается BPF ksock – API, позволяющий BPF-программам работать с сетевыми сокетами и отправлять данные напрямую из ядра. Изначально проект ориентирован на передачу телеметрии, событий и уведомлений без необходимости обрабатывать их в отдельном пользовательском процессе.

В первой реализации API доступны пять kfunc для создания UDP-сокета, подключения к удалённому адресу, отправки данных и управления временем жизни сокета. Это позволит, например, передавать события безопасности из BPF LSM даже при недоступности пользовательского агента, а также снизить накладные расходы на копирование и обработку телеметрии.

Авторы рассматривают и более широкие сценарии — от heartbeat-механизмов до DNS-серверов внутри ядра. Пока API ограничен рядом типов BPF-программ и UDP, но в планах – полноценная поддержка TCP, приёма данных и дополнительных операций с сокетами.

Ребята из NVIDIA выложили в открытый доступ свой проект Run:ai, который превращает GPU-серверы в общую AI-платформу.

Если вам знакома ситуация: одна команда ждёт GPU для обучения, другая держит видеокарту под почти пустой Jupyter Notebook, а у третьей ресурсы простаивают «на всякий случай», то данное решение поможет все это разрулить.

Run:ai решает эту проблему на уровне инфраструктуры. Это платформа поверх Kubernetes для управления GPU-ресурсами и AI-нагрузками: разработкой, обучением и инференсом.

Что умеет:
- Объединять ресурсы в общий пул. Команды получают квоты и правила доступа вместо навсегда закреплённых серверов.
- Использовать свободную мощность. Проект может выходить за свою обычную долю, пока ресурсы не нужны другим — в рамках заданных политик.
- Выделять доли GPU. Небольшим задачам не обязательно занимать целую видеокарту.
- Управлять конкуренцией. Очереди, приоритеты, fair-share, вытеснение и размещение с учётом топологии помогают распределять ресурсы между нагрузками.
- Давать общую картину. Единое управление несколькими Kubernetes-кластерами, мониторинг загрузки и контроль доступа.

Отдельные механизмы есть и в других инструментах, в Run:ai это все объединено в готовую платформу для совместной работы команд.

native.cloud – открытый проект, который предлагает единый словарь ключей для метаданных в облачной инфраструктуре. Идея появилась ещё в 2020 году, а запустили сайт в 2026-м. Проблему он решает знакомую: каждая команда и каждый инструмент называют одно и то же по-своему, и из-за этого буксует автоматизация.

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

Стандарт добровольный, вендорно-нейтральный и бесплатный, а сами авторы честно просят не добавлять ключи «для галочки».

В официальном блоге Anthropic вышла статья "Using Claude to reduce the attack surface of code", которая особенна интересна в свете последнего большого количества критичных уязвимостей.

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

Логика простая: закрытая критическая уязвимость ничего не говорит вам об оставшихся. А вот сокращение reachable-кода снижает критичность тех багов, о которых вы ещё не знаете — включая те, что прямо сейчас эксплуатируют.

В данном исследовании они обращают внимание на:
1) Default-конфигурацию — какой код доступен извне «из коробки», хотя дефолтным сценариям он не нужен.
2) Взаимодействие настроек — опции, безобидные по отдельности, но вместе тихо отключающие контроль.
3) Ранняя достижимость — какой код может дёрнуть внешний ввод до аутентификации.

Далее авторы приводят результаты своей работы на OSS решениях.

В нашей теме контейнерной безопасности все это также работает и оправдано, просто является еще одним рубежом уменьшения поверхности атаки. В контейнерном мире без редактирования кода можно:
- уменьшать количество системных вызовов (seccomp)
- уменьшать возможности кода (capabilities)
- уменьшать что в контейнере запускается (AppArmor,eBPF_LSM, ...)
- уменьшать свойства самого контейнера (SecurityContext)
- уменьшать сетевую доступность и активность микросервиса (NetworkPolicy)
- уменьшать разновидности и многообразие Kubernetes ресурсов (PolicyEngine)

Честно благодаря такой возможности ограничить поверхность атаки, я и полюбил данную тему)

Всем, привет!

В этом году в рамках SOC Forum 2026 наша команда продолжит делиться полезной информацией для SOC в окружениях на базе Kubernetes. В этом году поговорим про реагирование на инциденты!

PHP2Shell – две критические уязвимости с оценкой CVSS 9.2, позволяющие удалённо выполнить код на сервере. Пока нактываются патчи, уязвимые PHP нагрузки в Kubernetes остаются под угрозой, а одного сканирования образов недостаточно.

В нашей новой статье показываем, как Luntry обнаруживает и останавливает эксплуатацию PHP2Shell на уровне Runtime. Поведенческий анализ выявляет запуск shell из web-процесса и другую подозрительную активность, а Reaction Policies позволяют собрать артефакты для расследования и остановить контейнер.

Security Gates дополнительно блокируют деплой образов с критическими уязвимостями, доступными по сети и имеющими эксплойт. Как Luntry помогает защитить контейнеры в период между обнаружением уязвимости и установкой патчей – в полной статье.

Бессомненно можно сказать, что появление и бум AI-агентов дал новое дыхание технологиям виртуализации с акцентом на microVM!

Опять же Microsoft выпустила NVX: An Ultra-Light Micro-VM Sandbox с поддержкой Linux/KVM, Linux/MSHV, Windows/WHP. не путать с проектом Microsoft eXecution Container (MXC), о котором мы недавно писали.

Это родственные инструменты для безопасной изоляции (песочниц) ненадежного кода, созданные в первую очередь под задачи ИИ-агентов. Однако они находятся на разных уровнях абстракции и решают разные задачи. Главное отличие: MXC — это универсальная высокоуровневая платформа (SDK) управления песочницами, а NVX — это один из специализированных низкоуровневых бэкендов изоляции (сверхлегкая microVM), который сам MXC может использовать под капотом.

NVX больше похож на легковесную замену Docker/QEMU для специфических изолированных окружений. Он поставляется в виде CLI-инструмента командной строки и готовых образов (Alpine, Ubuntu, Azure Linux).

AI агенты в Kubernetes требуют не только изоляции, но и контроля над действиями. Обычный контейнер не гарантирует достаточной защиты. Агент может работать с секретами, обращаться к сети и выполнять недоверенный код.

В статье Isolation. Security. Scale. разбирают связку kagent и Agent Substrate для безопасного запуска агентов. Изоляция строится на двух уровнях – gVisor перехватывает системные вызовы, а microVM обеспечивает дополнительную границу на уровне виртуализации.

Отдельный акцент авторы делают на масштабировании и мультитенантности. Агенты запускаются на время активной сессии, а после её завершения освобождают ресурсы. Такой подход позволяет приблизить запуск AI агентов в Kubernetes к production-ready модели, где изоляция, политики безопасности и управление жизненным циклом работают вместе.

Прошел SOC Forum 2026 и хочется поделиться кулуарными инсайдами после общения с коллегами, отвечающими за SOC, реагирование, форензику в различных компаниях (внутренние и внешние SOC).
Основные 3 момента:
1) Инцидентов связанных с контейнерами и Kubernetes стало куда больше
2) Использование GTFOBins превалирует над использованием какого-то специального ВПО
3) Скорость атакующих растет

Касательно последнего пункта хочется сказать отдельно, что виднеется рука AI, и то что появляются повышенные требования к скорости реагирования - просто обнаружить уже недостаточно. На наш взгляд так вообще пора уже серьезно заниматься предотвращением, а то иначе вы не успеете...

AI-агенты не просто генерируют текст – они исполняют код, работают с файловой системой и обращаются к сети. В Kubernetes это создаёт риски выхода из контейнера, кражи секретов и lateral movement, особенно если агент обрабатывает данные, содержащие prompt injection.

В статье Untrusted Code, Trusted Cluster Scaling Secure AI Agent Workspaces with GKE Agent Sandbox разбирается GKE Agent Sandbox – решение Google для изоляции недоверенного кода на базе gVisor. Вместо прямого обращения к ядру хоста системные вызовы обрабатывает пользовательское ядро Sentry, а песочницы можно запускать менее чем за секунду.

Для production автор также рекомендует разделять управляющие сервисы и исполнителей по разным пулам узлов, ограничивать сетевой egress трафик и время выполнения задач. При этом sandbox не заменяет RBAC, сетевые политики и защиту секретов, а дополняет их изоляцией на уровне ядра.

При защите контейнерных приложений в Kubernetes (да и не только) с его обилием механизмов безопасности, подходов и инструментов многие часто задаются вопросом: "А что делать в первую очередь?".

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

Но с учетом быстро меняющей реалий, касаемых возможностей атакующего с обилием новых критичных уязвимостей как в популярных, так и нет библиотеках и ПО можно (да и нужно) одним из главных критериев становится: "Влияет ли механизм/подход/инструмент на поверхность атаки?". Которая как не сложно догадаться напрямую связана с моделью угроз и моделями нарушителей.

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

P.S. Сontainer specific OS, distroless, SecurityContext, NetworkPolicy, RBAC, prevention policies реально уменьшают поверхность атаки ...

Можно ли просто навесить на контейнер жёсткий seccomp профиль и считать проблему изоляции решённой? Нет, и дело не только в ошибках конфигурации. Seccomp контролируется тем же ядром, которое должен ограничивать, поэтому при эксплуатации kernel LPE атакующий потенциально может отключить эти ограничения.

Наглядная демонстрация – обход стандартного seccomp профиля container runtime через установку старшего бита в аргументе системного вызова socket(). Фильтр блокирует AF_ALG и AF_VSOCK, но пропускает те же значения с установленным битом 1 << 32, поскольку не учитывает разницу между 64-битным аргументом и его 32-битным представлением в ядре.

Отключить доступ к функции и изначально не предоставлять к ней доступ – принципиально разные вещи. Более надёжная модель изоляции выносит полномочия на уровень хоста, не полагаясь исключительно на ограничения внутри гостевой системы. Seccomp остаётся полезным дополнительным уровнем защиты, но не должен восприниматься как самостоятельная граница изоляции.

На нашем сайте Luntry стали доступны слайды "Реагирование на инциденты в Kubernetes для SOC"! А на сайте SOC Forum 2026 в разделе "Онлайн-трансляция" в зале Физика можно найти запись выступления.

Любая обратная связь и вопросы по данному исследованию приветствуется в комментариях к данному посту!

В Docker Desktop для Windows обнаружена критическая уязвимость CVE-2026-112917 с оценкой CVSS 4.0 – 9.2. Проблема затрагивает конфигурации с WSL2 и позволяет непривилегированному Linux контейнеру обойти ограничение seccomp для сокетов AF_VSOCK, используя 32-битный системный вызов socketcall.

В результате контейнер может получить доступ к службам хостовой системы и файлам Windows, доступным текущему пользователю. По сути, это нарушение границы изоляции между контейнером и хостом. Уязвимость не затрагивает Docker Desktop на базе LinuxKit.

Для устранения проблемы необходимо обновить Docker Desktop до версии 4.98.0 и выше, а WSL – до версии 3.0.3 и выше. Обновление только одного из компонентов недостаточно.

Уже 23 ноября в Москве состоится второй Kuber Conf от АОТ!

Возможно вы пропустили, но создатели данного канала (в лице Дмитрия Евдокимова (Luntry)) входят в экспертный совет АОТ и активно участвуют в подготовке конференции. Но речь сегодня не об этом.

Мы будем проводить на наш взгляд очень интересный круглый стол: «Kubernetes победил, и это проблема?». Король оркестраторов выбран единогласно — Kubernetes. Насколько это хорошо, целесообразно ли всё оборачивать в операторы и описывать через Custom Resources, есть ли сегодня альтернатива k8s и какой смысл в создании своих инструментов для оркестрации — про всё это и многое другое мы подискутируем на круглом столе.

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

Всем хорошей, продуктивной недели!

Portainer представила третью версию платформы, в которой Kubernetes становится основным направлением развития. Docker Standalone, Swarm и Podman продолжат получать обновления безопасности, но новые функции будут разрабатываться преимущественно для Kubernetes. При этом существующие Docker-сценарии можно будет сохранить с помощью Portainer-D2K.

Интереснее всего обоснование этого решения — опубликованная вместе со статьёй модель угроз The Container Platform Threat Model. Она рассматривает шесть платформ с позиции атакующего, использующего LLM для поиска уязвимостей, создания эксплойтов и последующего выхода из контейнера на уровень runtime или ядра. Отдельно разбираются атаки через отравленные образы и зависимости, компрометация API, prompt injection AI-агентов и горизонтальное перемещение между узлами.

Kubernetes предоставляет механизмы принудительного контроля на уровне API Server – Pod Security Admission, RBAC, NetworkPolicy и User Namespaces. В Docker Standalone и Swarm многие ограничения можно обойти, обратившись напрямую к Docker API, минуя управляющий интерфейс. Поэтому авторы считают Kubernetes более подходящей основой для защиты контейнерных платформ в условиях развития AI-assisted атак.