k8s (in)security

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. Нам удалось успешно воспроизвести уязвимость.

Немножко про container-specific OS и облачных провайдеров.

- У Google Cloud Platform (GCP) есть Container-Optimized OS (COS), которая разработана на базе Chromium OS.
- У Amazon Web Services (AWS) есть AWS Bottlerocket, которая является разработкой с 0 на Rust.
- У Azure теперь есть Azure Container Linux (ACL), которая спроектирована как downstream-версия Flatcar Linux, разработчика которого (Kinvolk) Microsoft купила в 2021 году.

Начиная с июня 2026 года, AKS прекратил поддержку оригинального Flatcar Container Linux. Microsoft официально рекомендует пользователям мигрировать на Azure Container Linux (ACL), который стал его полноценной заменой в экосистеме управляемого Kubernetes от Azure.

Но ранее в 2024 дистрибутив Flatcar Container Linux был полностью передан независимому фонду Cloud Native Computing Foundation (CNCF) для сохранения его нейтральности и открытости. По идее в рамках этого уже без участия Microsoft проект должен развиваться сам.

Security Profiles Operator (SPO) выпустил первый стабильный релиз v1.0.0 — все восемь его API типа CRD переведены на версию v1. Проект позволяет управлять профилями безопасности Linux (seccomp, SELinux, AppArmor) как кастомными ресурсами Kubernetes, записывать их с живых нагрузок и привязывать к подам декларативно. Мы не раз говорили об этом проекте на канале.

Релиз прошёл сторонний аудит безопасности, который не выявил критических уязвимостей, но подсветил зоны для укрепления. Команда закрыла эти находки: добавила строгую валидацию входных данных AppArmor, заменила рискованный флаг permissive на enum-режим у SelinuxProfile и дала админам возможность полностью отключать самый опасный путь — raw SELinux-профили.

Обновление проходит без простоя: conversation-вебхуки прозрачно переводят старые манифесты (v1alpha1, v1alpha2, v1beta1) в v1, так что ручная миграция не требуется. Отдельно интересно, что наработки SPO по распространению профилей через OCI-реестры теперь ложатся в основу апстрим-предложения KEP 6061, встраивающего эту концепцию прямо в kubelet Kubernetes.

Из статьи "Automating Penetration Testing with SecureCodeBox on Kubernetes Kind Clusters Using GitHub Actions" вы узнаете как можно автоматизировать пентест с помощью проекта SecureCodeBox (о котором мы писали еще 4 года назад), который работает как Kubernetes оператор.

Massimiliano Oldani (sgrakkyu) опубликовал PoC, который из непривилегированного процесса внутри изолированного по сети контейнера даёт полноценный побег на хост с root. В основе — свежезакрытая уязвимость IPv6-стека ядра Linux: при сборке UDPv6-фрагментов через splice() ядро выделяло буфер только под заголовки, забывая про перенос выровненных байтов (fraggap), и запись уходила за конец объекта прямо в служебную структуру skb_shared_info.

Дальше один испорченный байт nr_frags разворачивается в page use-after-free и технику Dirty Pagetable с произвольным чтением/записью ядра: KASLR обходится через SMP-трамплин, SELinux глушится подменой пролога avc_denied(), а сам побег из контейнера делается через core_pattern. Всё срабатывает детерминированно, без heap-grooming и без каких-либо привилегий.

Баг тихо жил с ядра 6.0, но эксплуатировать его стало возможно только с версии 6.6, после которой он попал во все поддерживаемые ветки и был незаметно убран коммитом в середине июня — без CVE, без advisory и без бэкпорта в stable, что автор и критикует: фикс лежит в открытом дереве, фактически раздавая рабочий 0-day. Опубликованный PoC намеренно ослаблен и работает только на ядрах без CONFIG_INIT_ON_ALLOC (RHEL/CentOS). Боевую версию обещают после выхода патчей.

Сегодня в центре нашего внимание будет Keynote доклад "Offense and Defense in an Era of Systemic Asymmetry: Why the Old Model No Longer Holds" от Aaron Portnoy с Ekoparty Miami 2026. Это самый крутой Keynote доклад, который я слушал за последнее время и могу рекомендовать как blue/red teams, так и C-level.

К мнению этого человека c 20 летним опытом в offensive security определённо стоит прислушиваться. Для понимания он начинал в легендарном Zero Day Initiative (ZDI) и является создателем соревнования Pwn2Own (и 15 лет назад я учился по его статьям реверсу, IDAPython и поиску уязвимостей).

Из выступления вы узнаете:
- Как AI/LLM меняют баланс для защиты и атаки
- Про когнитивное нападение и стремление к когнитивной защите
- Почему разрыв между атакой и защитой будет становиться только больше
- Почему простое встраивание AI в существующие инструменты потерпит провал

Реально MUST WATCH!

P.S. Доклад не про контейнеризацию и K8s, но он чрезвычайно важен всем для понимания того как меняется баланс в безопасности с учетом AI. Там есть ряд мыслей, которые звучат и у меня в одном из докладов, который пока звучит только на закрытых мероприятиях.

P.S.S. Очень приятно было увидеть цитату с выступления с ZeroNights 2017 =)

C 18 июня сдача экзамена CKS (Certified Kubernetes Security Specialist) или его продление автоматически восстанавливает и продлевает сертификацию CKA (Certified Kubernetes Administrator). Дата истечения CKA теперь подтягивается к дате нового CKS — причём это работает даже если ваш CKA уже просрочен. По сути один успешный экзамен поддерживает обе сертификации актуальными.

CKS строится на знаниях и навыках CKA, так что прохождение CKS уже служит подтверждением базовых административных компетенций. Никаких дополнительных действий не требуется — после сдачи или продления CKS дата CKA обновится сама.

Особенно это удобно для Kubestronaut'ов, которым нужно держать активными сразу пять сертификаций Kubernetes.

Наверное правильнее было бы этот пост сделать в пятницу, ну ладно)

webernetes - Kubernetes в web-браузере.

Вы спросите зачем такое вообще?

В общем, ребятам для обучающих целей не хочется держать и поднимать реальную инфраструктуру и они пошли по пути browser-based симулятора =)

Live Demo.

Контейнеры не изолируют приложения магически — за этим стоят конкретные механизмы Linux ядра: пространства имён, capabilities и bind mounts. Доклад "Know "Con Fu"! Container security techniques and the Canon of eBPF" разбирает эти механизмы с нуля, от базовых принципов до продвинутых техник.

Райнхард Коглер показывает обе стороны медали: как атакующий использует особенности ядра для побега из контейнера и как защитник применяет те же знания для обнаружения и блокировки угроз.

Ценность доклада в системном подходе: понять контейнерную безопасность по-настоящему можно только разобравшись, как Linux работает под капотом. Обязательный материал для всех, кто эксплуатирует Docker или Kubernetes в продакшене.

В 2026 году очень сложно удивить каким-либо способом доставки secret до приложения. Особенно это сложно с учетом доклада Валеры Кунавина "От стандартных к нестандартным методам управления секретами в контейнерах" с конференции БеКон 2024.

НО сегодняшнему герою как мне кажется это удалось сделать.

Kloak - инструмент, который с помощью eBPF uprobes перехватывает исходящий TLS-трафик в Kubernetes, заменяя хешированные placeholders реальными секретами на уровне ядра перед шифрованием. Приложения никогда не обрабатывают фактические учетные данные, и не требуется никаких sidecar-контейнеров или изменений в коде.

Проект поддерживает:
- Хуки в OpenSSL, BoringSSL и нативном Go crypto/tls.
- Работу с Python, Node.js, Go, Rust, Ruby, PHP, curl и любым OpenSSL-linked runtime.

Сontainerd выпустил патчи для пяти уязвимостей, и четыре из них связаны с одним механизмом — восстановлением контейнеров из checkpoint образов в CRI-плагине.

Самые опасные позволяют через недоверенный checkpoint-образ прочитать произвольный файл на хосте по символической ссылке (CVE-2026-53489), протащить CDI-аннотации и получить доступ к устройствам хоста (CVE-2026-53492), а также подменить локальные теги образов (CVE-2026-50195).

Отдельно стоит уязвимость CVE-2026-53488: метки из конфига образа (инструкция LABEL в Dockerfile) пробрасываются в контейнер без валидации, что в итоге может привести к выполнению команд от root прямо на хосте при простом pull образа. Пятая (CVE-2026-47262) — это DoS: специально собранный образ вызывает исчерпание памяти и OOM-kill процесса containerd, выводя из строя весь runtime API.

Обновляйтесь до 2.3.2, 2.2.5, 2.1.9, 2.0.10 или 1.7.33, а до обновления используйте только проверенные образы и ограничьте круг тех, кто может импортировать образы или запускать поды.

Ото дня ко дню все чаше в инфо поле мелькают AI агенты и AI сгенерированный код. Который по сути равносилен не доверенному коду. Мы писали уже об этом (1,2,3,4).

Но так или иначе надо этот код запускать и обеспечивать его изоляцию и безопасность.

Так что не удивительно что под такую специфичную задачу появляются и специализированные/заточенные решения.

На пример, проект Isola.

Это проект с открытым исходным кодам как раз для запуска такой AI не доверенной нагрузки в кластере Kubernetes с использованием gVisor рантайма для изоляции от ядра хостовой ОС. при этом система декларативно через Custom Resources позволяет управлять как самими sandboxes, так и snapshots файловой системы (для прогретого запуска). А сетевая изоляция реализована с помощью классического ресурса NetworkPolicy, тоесть тоже декларативно и максимально удобно.

P.S. При желании вам никто не мешает собрать/добавить подобное в свой ванильный кластер ;)

Инженеры DoubleVerify рассказали, как собирать метрики производительности из приложений, развёрнутых в инфраструктуре партнёров, которая остаётся для них «чёрным ящиком». Решением стал Vector от Datadog — лёгкий open-source инструмент для сбора, преобразования и маршрутизации логов, метрик и трейсов в любые системы мониторинга.

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

Vector разворачивается в Kubernetes как StatefulSet. При этом инструмент гибок и поддерживает разные схемы развёртывания, а также работу с Loki, Splunk и Datadog помимо Prometheus.