Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать AI-агенты, AI сгенерированный код. Мы также уже неоднакратно писали на эту тематику. Например, про проект Docker Sandboxes - тут, тут и тут.

Но для тех кто не знает или не помнит, напомним что это решение для macOS и Windows представляет из себя MicroVM и базируется на платформенных фреймворках виртуализации: Apple Virtualization.framework на macOS и Hyper-V на Windows.

Должно быть надежно?!

CVE-2026-79994 и CVE-2026-77179 ломают эту изоляцию ... Побег из VM на host из-за очередных проблем с symlink....

P.S. В процессе подготовки удалось словить забавное от нейронки Google Gemini, которая считает что в изолированных песочницах на macOS можно запускать только доверенные приложения )))))) наверное она что-то знает еще)))))

В официальном блоге Kubernetes появилась заметка "Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions". Она описывает новые возможности по безопасности хранилищ (Storage):
1) Права доступа на emptyDir - на пример 01777 через emptyDir mode
2) bind mount опции - такие как noexec, nodev, nosuid через bindMountOptions 

Обе фичи находятся в Alpha статусе и называются VolumeBindMountOptions и EmptyDirVolumeMode.

Очень здорово, что разработчики с каждым релизом подтягивают тот или иной аспект безопасности k8s.

Из статьи "Migrating a critical Kubernetes deployment from the default namespace without any downtime" можно узнать как мигрировать микросервисы из одного namespace (не обязательно default - тут он только для примера) в любой другой namespace без простоя.

Главная идея статьи сохранение старого DNS-адреса как точки совместимости. В старом namespace можно временно оставить Service типа ExternalName, который перенаправляет запросы на сервис в новом namespace. Поэтому такой сценарий применим, например, при переносе:
- из payment в payments;
- из общего namespace в namespace команды;
- из временного namespace в production namespace;
- между namespace разных окружений внутри одного кластера.

При это внутренний и внешний трафик нужно рассматривать отдельно: перенос Service сам по себе не решает проблему Ingress. Как и по каким шагам все это сделать, какие есть подводные камни и исключения описано в данной статье.

Цикл статей "User Namespaces in Kubernetes":
1) Part I: All You Need to Know
2) Part II: Mappings and File Ownership
3) Part III: The Implementation

О User Namespaces мы писали очень много (1,2,3,4,..), но и в этом материалы вы точно найдете что-то новое и полезное ;)

P.S. Всегда будет полезно посмотреть доклад "Linux user namespace в чертогах Kubernetes" с БеКон 2024

В Kubernetes была закрыта новая уязвимость.

CVE-2026-2270: StatefulSet and ControllerRevision write permissions allow cross-namespace pod creation

Уязвимость в kube-controller-manager, тоесть придется обновлять master nodes.

CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
Medium (5.9)

Пользователь с правами на изменение объектов StatefulSet и ControllerRevision в своём namespace потенциально может добиться создания Pod в другом namespace — с заданными им метаданными и конфигурацией.

Для эксплуатации нужны соответствующие права, а созданный Pod обычно удаляется сборщиком мусора. Чтобы он сохранился, атакующему потребуется корректно указать OwnerReference, включая UID существующего StatefulSet в целевом namespace.

Начнем неделю со статьи "Scale your AI workloads faster and more efficiently with GKE Pod snapshots", которая рассказывает как в GKE можно замораживать (checkpoint) состояния Pod в виде snapshot и затем запускать их с этого же момента (restore). Более подробно можно узнать об этом из документации "Save and restore Agent Sandbox environments with Pod snapshots".

И если вам кажется, что это какая-то магия и доступна только избранным пользователям GKE Sandbox, то вы ошибаетесь - такое можете сделать и вы сегодня у себя дома. Так как это все базируется на возможностях рантайма gVisor (1,2)!

Да, это еще не реализация в рамках runc/crun и KEP-5823 (Pod-level Checkpoint/Restore) на базе CRIU, но тоже вариант ;)

Сконцентрировавшись на серверной части инфраструктуры, мы порой непростительно забываем про клиентскую историю. Так вот очередная уязвимость в Kubernetes, напоминает нам о том что надо защищать и патчить не только компоненты control и data plane, но и kubectl.

CVE-2026-19444: kubectl cp path traversal on Windows allows arbitrary file writes

CVSS Rating: CVSS:3.1/AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N
Medium (6.5)

Если капнуть в историю, то это далеко не первая подобная бага в kubectl:
1) CVE-2018-1002100 — Первая оригинальная уязвимость kubectl cp
2) CVE-2019-1002101 — Атака через символические ссылки (Symlink Attack) в kubectl cp
3) CVE-2019-11246 — уязвимость обхода каталога (directory traversal) в команде kubectl cp
4) CVE-2019-11249 — закрывает обход предыдущих патчей для kubectl cp

Особенность новой уязвимости в том что она только под Windows. Проблема кроется в разнице обработки путей (например, разделителей путей \ против /, использования дисков C: или специфических для Windows символов), из-за чего общие кроссплатформенные проверки kubectl оказались неэффективны на Windows-системах, позволяя осуществлять несанкционированную запись произвольных файлов (arbitrary file write).

Сегодняшний наш герой это runtime security агент на eBPF под названием Bombini, который целиком написанный на Rust с библиотекой Aya.

Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.

Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AST,оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.

Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.

Подробнее о проекте можно узнать тут и тут.

Docker выпустил свой официальный набор skills для работы со своими решениями:
- Dockerfile & Build
- Docker Compose
- Docker Sandboxes
- Docker Agent
- Cross-Product

В общем если вы активно работаете с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться.

Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, какие доступы ему нужны.

Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime.

Но формат не ограничен агентами: им можно описывать потребности обычных сервисов!

По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру.

Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория.

P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года.

k8s-aibom - это оператор для сбора AI Bill of Materials в Kubernetes.

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

Команда Google Cloud представила k8s-aibom — инструмент с открытым исходным кодом, который помогает автоматически собирать AIBOM.
Что инструмент дает:
- инвентаризацию AI-компонентов в кластере;
- понимание, какие модели и ML-фреймворки используются;
- повышение прозрачности AI-нагрузок;
- помощь в анализе рисков, уязвимостей и соответствия требованиям безопасности;
- более удобный контроль AI-софта в production-средах.

Со временем окружение быстро усложняется, а ручной учет компонентов становится практически невозможным. По сути, k8s-aibom — это попытка сделать для AI-компонентов то же, что SBOM (только в формате OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM)) делает для обычного программного обеспечения: дать структурированное представление о составе системы, чтобы защитить цепочку поставки (supply chain), борьба с shadow AI.

Исследователи Palo Alto Networks показали интересный сценарий атаки на SPIFFE/SPIRE в Kubernetes. Если атакующий получает root на ноде, он может подменить cgroup метаданные процесса и заставить SPIRE Agent выдать ему SVID другого workload.

В результате злоумышленник получает возможность использовать криптографическую идентичность скомпрометированного workload и обращаться к сервисам, доверяющим этой identity. При этом сама криптография SPIFFE не ломается — проблема в том, что после компрометации ноды рушится доверие к данным, на которых основана workload attestation.

Для проверки таких сценариев Palo Alto Networks выпустили открытый инструмент Spooffe, который автоматизирует тестирование подмены cgroup и получения чужих SVID. Хорошее напоминание о том, что SPIFFE/SPIRE не изолирует workload от полностью скомпрометированной ноды и root доступ нужно учитывать в threat model.