В свежем посте Solving secret sprawl in multi-account Kubernetes with External Secrets Operator в блоге CNCF разбирают типичную боль multi-account Kubernetes: окружения dev/staging/prod изолированы по разным аккаунтам и кластерам, и общие секреты приходится вручную дублировать и обновлять в каждом из них.

Авторы решили проблему связкой External Secrets Operator и Bitwarden Secrets Manager: секреты хранятся централизованно в одном месте, а ESO в каждом кластере автоматически синхронизирует их в обычные Kubernetes Secrets. Приложения при этом ничего не замечают и продолжают работать со стандартными механизмами, а сам подход provider-agnostic — вместо Bitwarden можно подставить Vault, AWS Secrets Manager или Azure Key Vault.

В статье есть пошаговый гайд с манифестами (включая настройку TLS через cert-manager) и ссылка на Terraform автоматизацию. Ключ ротируется один раз в центральном хранилище, и в течение 15 минут все кластеры получают обновление автоматически.

Компания Microsoft продолжает развивать Linux подсистему в рамках своей Windows и в этом можно убедиться в рамках нового доклада "WSL improvements and the new Containers CLI and APIs". И да, тему контейнеров там они тоже улучшают!

Из данного доклада вы узнаете:
1) Общее назначение
2) Появление CLI утилиты WSLC для управление контейнерами
3) Сборка Custom Images
4) Появление NuGet-based API для взаимодействие по API с теме же Windows приложениями
5) WSL Containers SDK
6) Про архитектуру

Все это демонстрируется с примерами и в основном упор на AI, ML, GPU тасках (ну понятно куда все это идет). В общем, это отличный вариант изолированно запускать агентов и выдавать им ограниченный доступ у себя на Windows машине.

ClusterHound — это инструмент, который встраивает Kubernetes в BloodHound. С помощью kubectl он собирает топологию кластера и его RBAC-конфигурацию, после чего выгружает результат в OpenGraph JSON для импорта. Главная идея в том, что многошаговые цепочки атак в Kubernetes — захват сервис-аккаунтов, эскалация привилегий, побег с хоста, доступ к секретам — превращаются в проходимые рёбра графа, по которым можно строить маршруты атак.

Под капотом кластер моделируется как 15 типов узлов и 27 типов рёбер, а рёбра отдаются как structured graph, который нативно понимает встроенный pathfinding BloodHound. В комплекте идёт 31 готовый Cypher-запрос — от анализа точек входа до кратчайших путей до полной компрометации кластера. Инструмент работает только на чтение (get/list) и мапит ровно столько, сколько видят используемые учётные данные, поэтому его можно запускать как на весь кластер, так и в рамках отдельных namespace.

Требуется Python 3.8+, kubectl и BloodHound CE версии 9.0 и выше. Проект активно развивается.

Как-то так получилось, что за все время существование канала мы не писали о таком проекте как Darp (Distributed Application Runtime).

По сути это универсальный runtime-слой для микросервисов и event-driven приложений, который делает распределённую разработку проще, переносимее и менее зависимой от конкретной инфраструктуры.

В отличие от service mesh вроде Istio или Linkerd, Dapr ориентирован не только на сетевое взаимодействие, а на прикладные building blocks: state, pub/sub, bindings, actors, workflows. Service mesh решает в основном задачи трафика, безопасности и observability между сервисами.

В отличие от Spring Cloud, Micronaut или других framework-based решений, Dapr не требует писать приложение на конкретном языке или фреймворке. Он работает с любым языком, потому что предоставляет внешние HTTP/gRPC API.

В отличие от SDK для облачных сервисов, Dapr даёт абстракцию над провайдерами. Можно заменить Redis на PostgreSQL, Kafka на RabbitMQ или Azure Service Bus без серьёзного изменения бизнес-кода.

В отличие от Kubernetes-native операторов, Dapr не только управляет инфраструктурой, но и предоставляет runtime API, с которым напрямую взаимодействует приложение.

P.S. Есть кто его использует?

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

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

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

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

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

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

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

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

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

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

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