В 2014 году Google явил миру оркестратор Kubernetes, чтобы управлять множеством контейнеров на множестве хостов, и который сегодня стал стандартом де-факто в индустрии.

И уже в 2026 году Google явил миру оркестратор ax (agent executor), чтобы управлять множеством автономных агентов в кластере Kubernetes. Станет ли он стандартом де-факто в индустрии покажет лишь время.

AX — это инфраструктура для запуска ИИ нагрузок и работает это дело по верх k8s и Agent Substrate. В его основе три сущности (YAML):
1) Task — задача в изолированной среде: образ контейнера, команда, переменные окружения, запросы и лимиты вычислительных ресурсов.
2) Workspace — рабочее окружение: Git-репозитории, MCP-серверы и пакеты навыков. Можно задать цель обычным языком, например «подготовить Go toolchain», и агент займётся настройкой окружения перед запуском основной команды.
3) Model — конфигурация провайдера и модели, параметры генерации и ссылки на Kubernetes Secrets с учётными данными.

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

Kubernetes продолжает переход на cgroup v2, а поддержка cgroup v1 постепенно уходит в прошлое. Начиная с Kubernetes 1.35, kubelet по умолчанию отказывается запускаться на узлах с cgroup v1, а в версии 1.38 поддержку старого механизма планируют удалить.

Переход на cgroup v2 даёт единую иерархию управления ресурсами, улучшает изоляцию и открывает доступ к новым возможностям, включая Memory QoS, метрики PSI и более точное управление ресурсами Pod. Кроме того, контроллер устройств в cgroup v2 реализован через cgroup BPF, что важно для инструментов на базе eBPF.

При миграции стоит проверить версии ядра Linux, containerd или CRI-O, настройки cgroup driver и совместимость инструментов мониторинга, которые напрямую читают файловую систему cgroups. Для новых кластеров рекомендуется сразу использовать cgroup v2, а для существующих — заранее спланировать миграцию. Об этом и не только довольно подробно рассказывают в заметке из официального блого Kubernetes – The Shift to cgroup v2 in Kubernetes: What You Need to Know.

Завтра в рамках отраслевого форума по информационной безопасности ITSEC 2026 наша команда представит 2 доклада:

1) Как не завалить SIEM в высоконагруженных кластерах Kubernetes

Кластера Kubernetes генерирует большой поток событий, что на уровне Runtime, что на уровне Kubernetes Audit Log. И если эту задачу решать в лоб, то либо складывается агент и хост вместе с ним, либо улетучивается вся лицензия на SIEM вместе с дисковым хранилищем. Как быть и что делать рассмотрим в данном докладе.

2) Защита AI-инфраструктур

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

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 в разделе "Онлайн-трансляция" в зале Физика можно найти запись выступления.

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