k8s (in)security

Исследователи 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.

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.

Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, какие доступы ему нужны. Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime. Но формат не ограничен агентами: им можно описывать потребности обычных сервисов! По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру. Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория. P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года.

Docker выпустил свой официальный набор skills для работы со своими решениями: - Dockerfile & Build - Docker Compose - Docker Sandboxes - Docker Agent - Cross-Product В общем если вы активно работаета с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться.

Сегодняшний наш герой это runtime security агент на eBPF под названием Bombini, который целиком написанный на Rust с библиотекой Aya. Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра. Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AS`T, оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в `eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ. Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно. Подробнее о проекте можно узнать тут и тут.

Сконцентрировавшись на серверной части инфраструктуры, мы порой непростительно забываем про клиентскую историю. Так вот очередная уязвимость в 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).

Начнем неделю со статьи "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 была закрыта новая уязвимость. 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.

Цикл статей "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

Из статьи "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. Как и по каким шагам все это сделать, какие есть подводные камни и исключения описано в данной статье.

В официальном блоге 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.

Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать 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 можно запускать только доверенные приложения )))))) наверное она что-то знает еще)))))

Итоги конкурсов! Конкурс: "Самый желанный доклад". Победитель @Nuclearm С докладом про «как мы выпилили k8s и стали спать по ночам: история одного отказоустойчивого монолита». хочу услышать, как команда решилась и что потеряла. Конкурс: "Самая опасная уязвимость в Kubernetes" Победитель @pharma_unsafe С багой в драйвере Поздравляем победителей! Победителям отдельно напишем в ЛС и расскажем как получить проходки.

Если UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит: 1) server room 2) the rack =) Всем хороших выходных! P.S. Результаты конкурсов объявим в 18:00 по Мск.

Завтра последний день, чтобы поучаствовать в конкурсах и выиграть проходку на: 1) DevOops 2026 - участвовать! 2) ZeroNights 2026 - учувствовать! еще есть время ;)

Наша команда R&D обнаружила критическую уязвимость в NeuVector — CVE-2026-78424. Проблема находится в механизме packet capture и позволяет через специально сформированный фильтр добиться OS Command Injection в привилегированном enforcer контейнере. Для эксплуатации достаточно низких привилегий — атакующему требуется доступ с правом записи в namespaced Runtime Policies. В результате выполнение команд внутри контейнера может привести к полной компрометации worker ноды Kubernetes, а самой уязвимости присвоен CVSS 9.4. Мы сообщили об уязвимости разработчикам NeuVector 7 августа, после чего она была исправлена в версиях 5.6.2, 5.5.4 и 5.4.11.

Я долгое время считал, что подход/термин “Shift Down Security” появился в материале SIG Security Kubernetes в 2025 году. Но на самом деле корректнее считать 2023 год и статью ребят из Google Cloud под названием "The Modernization Imperative: Shifting left is for suckers. Shift down instead"! Автор статьи критикует чрезмерное «shift left» — перенос на разработчиков всё большего числа задач: тестирования, безопасности, эксплуатации, релизов и т. п. Хотя раннее подключение QA и security полезно, но на практике это нередко превращает инженеров в перегруженных «универсалов». Вместо этого он предлагает «shift down» подход : передавать сложность вниз, на управляемые платформы и абстракции.

30 сентября в Санкт-Петербурге пройдет легендарная конференция по информационной безопасности - ZeroNights! На сайте доступна программа, а наша команда Luntry будет рада видеть вас на своей зоне и поболтать на тему безопасности контейнеров и Kubernetes! И мы рады запустить еще один конкурс с проходной на конференцию. Конкурс: "Самая опасная уязвимость в Kubernetes" Предыстория: На мой взгляд на текущий момент самой критичной уязвимостью найденной в Kubernetes является CVE-2018-1002105 в kube-apiserver, которая позволяла по итогу обход механизма авторизации! Задание: Придумайте, какая уязвимость в Kubernetes могла бы по критичности быть на том же уровне или еще выше ;) Критерий оценки: - Реалистичность - Оригинальность - Технические детали Итоги: 18 сентября

Свежевышедшая версия Cilium 1.20 заметно расширяет роль Gateway API. Помимо перехода на Gateway API v1.6, появились ExternalAuth для проверки запросов через внешний authorization service, а также TCPRoute и UDPRoute для управления L4-трафиком через тот же API. Это позволяет использовать единый Gateway для HTTP, TCP и UDP сервисов вместо комбинации Gateway API и отдельных LoadBalancer/NodePort. Из сетевых изменений особенно интересно появление beta-поддержки IPv6 в AWS ENI IPAM, благодаря чему pod'ы в EKS могут получать маршрутизируемые IPv6 адреса из VPC. Также появился автоматический выбор netkit или veth в зависимости от версии kernel и возможность подключать собственные eBPF datapath plugins без форка Cilium. Отдельно стоит обратить внимание на per-pod отключение source IP verification. Теперь его можно разрешить только для конкретного namespace и workload, что позволяет сохранить anti-spoofing в остальном кластере.

На прошлой неделе мы писали пост про выход новой версии Kyverno, где была закрыта одна серьезная уязвимость. И так получилось, что автор этой находки наш читатель и автор еще многих интересных находок в cloud native проектах: Vault Secrets Operator, Capsule, Strimzi operator, Grafana operator, Fluent Operator, VictoriaMetrics Operator и еще ряда других, которые находятся в процессе исправления. Если вам интересна данная тематика, то можно следить за ними в блоге автора и его канале. Ну и вы можете заметить, что без помощи LLM тут не обходится =)