В 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.

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

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

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

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

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

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

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

Live Demo.

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

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

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

Сегодня в центре нашего внимание будет 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 =)

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). Боевую версию обещают после выхода патчей.

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

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.

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

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

Возможно вы помните как мы писали, что рабочая группа в рамках 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" ...

Исследователь под ником bikini опубликовал на GitHub целый набор из 23 эксплойтов для популярных проектов, включая FFmpeg, VLC, Firefox, Docker, PHP, OpenVPN, nmap, libssh2 и 7-Zip. Часть уязвимостей относится к категории 0-day, а сам код был создан с помощью fuzzing-инструментов в связке с AI-моделью.

Отдельно хотим отметить уязвимость в Docker. Команда docker cp при копировании файлов из контейнера на хост может обрабатывать символические ссылки таким образом, что позволяет вырваться за пределы указанного каталога и записать данные в произвольное место на хост-системе. То есть недоверенный контейнер потенциально способен перезаписать чужие файлы на машине, где выполняется копирование.

CVE идентификаторы для большинства находок пока не назначены, а публикация рабочих эксплойтов до исправления вызвала споры в сообществе о допустимости такого раскрытия.

О том, что NIST не справляется с наплывом уязвимостей и меняет свой подход по работе с CVE думаю видели и читали все.

Почти с аналогичным посылом в своем блоге выступила и команда GitHub в посте "Inside the Advisory Database and what happens when vulnerability volume breaks records".

Что и как делать в таких реалиях мы рассказывали в рамках доклада «Уязвимости в контейнерах и Kubernetes: правим, а не страдаем» c CISO ФОРУМ 2026.

Марафон 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.

Стала доступна запись эфира "Как развитие контейнеров влияет на информационную безопасность", где мы (Luntry) с коллегами из K2 вопросы специфики безопасности контейнерных окружений! Эфир получился очень интересным и задорным (особенно его вторая половина) - рекомендуем всем к ознакомлению ;)

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

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-агентов без риска для машины сейчас одна из самых горячих — стоит добавить в закладки.

Kelos - AI-агенты как нативные ресурсы Kubernetes

Все привыкли запускать кодинг-агентов локально: открыл терминал, набрал claude или codex, посидел рядом, посмотрел. Проект Kelos предлагает другой взгляд: а что, если агенты — это не одноразовые локальные команды, а декларативные ресурсы в кластере, как Deployment или CronJob?

Kelos добавляет в K8s набор CRD, которые превращают работу AI-агентов в часть control plane:
- Task — одиночный запуск агента с промптом (выполняется в эфемерном поде);
- Session — долгоживущий диалог на StatefulSet, к которому можно подключаться из веба или терминала;
- TaskSpawner — автоматическое порождение задач из GitHub Issues и PR, вебхуков, Jira или по расписанию;
- Workspace — описание git-репозитория с аутентификацией;
- AgentConfig — переиспользуемые наборы инструкций, плагинов и MCP-серверов.

Под капотом поддерживаются Claude Code, OpenAI Codex, Gemini, OpenCode, Cursor и произвольные контейнерные образы. Задачи можно связывать в цепочки через dependsOn с передачей результатов между этапами — получается полноценная оркестрация: один агент скаффолдит сервис, второй пишет тесты, третий готовит PR.

Что это даёт на практике:
1. GitOps для агентов. Промпты, конфигурации и workflow версионируются в git и раскатываются через kubectl/Helm — как любая другая инфраструктура.
2. Изоляция. Каждый агент живёт в своём поде без доступа к хосту и соседям, с RBAC, лимитами maxConcurrency и activeDeadlineSeconds.
3. Автономные пайплайны. Классический пример из README: TaskSpawner ловит issues с меткой bug и автоматически поднимает агента на исправление.

Недавно мы задались вопросом: Сколько CVE из официального Kubernetes feeds можно закрыть политиками PolicyEngine (Kyverno/Gatekeeper)?

И после нехитрого исследования получили следующие цифры.

1. Митигируется политиками (32 CVE)
1.1. Инъекции конфигурации ingress-nginx через объект Ingress (16 CVE)
1.2. Вектор — поля Pod/PV/Service/EndpointSlice спеки (16 CVE)

2. Частично митигируется (21 CVE)
Политика снижает вероятность/последствия, но не закрывает уязвимость: либо режет только часть векторов, либо требует хрупкой кастомной эвристики, либо «лечит» ценой отключения легитимной функциональности.

3. Не митигируется admission-политиками (38 CVE)
3.1. Баг в обработке запроса apiserver — срабатывает до/вне admission (8 CVE)
3.2. Протокольные/сетевые баги kubelet, kube-proxy, apiserver-прокси (7 CVE)
3.3. Уязвим сам admission-вебхук ingress-nginx (3 CVE)
3.4. Утечки секретов/токенов в логи control-plane (6 CVE)
3.5. Клиентские инструменты и библиотеки (4 CVE)
3.6. Инфраструктура вне кластера: Image Builder, ОС нод, сторонние UI (6 CVE)
3.7. Поведение рантайма/контроллеров, не выражаемое в admission-объектах (4 CVE)

PolicyEngine — не патч-менеджмент, а срез одного слоя. Но этот слой закрывает треть фида «малой кровью». Остальное — только обновления, RBAC, NetworkPolicy и контроль логов.

BTV K8s Sandbox — Kubernetes полигон для Blue Team

Blue Team Village к DEF CON 34 (Project Obsidian) выкатили self-contained Kubernetes-песочницу для CTF: поднимаешь локально, без общей инфраструктуры, и тренируешь defensive-скиллы на реальной малвари — но в изолированной инертной среде.

Под капотом:
- Minikube — кластер
- Tetragon — eBPF-телеметрия ядра
- Cilium — сеть и network policies
- Kyverno — admission control

Челленджи — два класса:
1) Standalone — форензика реальной Linux-малвари (21 шт.)
Малварь уже «подорвана», ты разбираешь следы в /forensics/tetragon-events.json и опознаёшь семейство по kernel-повадкам.
2) Converged Frontier — investigation-сценарии (10 × 2 трека)
Многоэтапные расследования с вводной и евиденсами в /challenge/. Каждый в двух уровнях: beginner и pro.

По сути — мини-SOC с kernel-level телеметрией, чтобы разбирать TTP атак форензик-методами, а не на проде ;)
Работает через Docker/colima (macOS) или Docker Desktop + WSL2.

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

Попытка ответа — CNAB, Cloud-Native Autonomous-attack Benchmark: полностью офлайновый детерминированный бенчмарк для оценки агентов на задачах chaining'а мисконфигураций (и на защите от них). Идея простая: любой может развернуть у себя ту же среду одной командой, подключить свою модель/своего агента (Claude, OpenAI, Gemini или локальные через LM Studio) и получить сравнимые цифры.

Внутри — 16 сценариев по Kubernetes (RBAC, NetworkPolicy), serverless (Lambda) и облачному IAM (AWS/Azure/GCP): от plaintext-кредов и IMDS/SSRF до оверпермишенов, с таксономией «фаза × домен × тип мисконфига» и уровнями сложности L1–L4.

Проект совсем свежий и пока безвестный, но направление правильное: рынок «агентных пентестеров» растет быстрее, чем способность заказчика проверить их маркетинговые заявления. И обратите внимание, что тут же встроена оценка синтеза защит — то есть бенчмарк одинаково полезен и тем, кто атакует, и тем, кто потом закрывает дыры =)