k8s (in)security

Как-то так получилось, что за все время существование канала мы не писали о таком проекте как 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. Есть кто его использует?

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 и выше. Проект активно развивается.

Компания 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 машине.

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

Статья "Mastering Kubernetes Security: A Deep Dive into SecurityContext" очень хорошо с примерами закрывает все вопросы по назначению, устройству, разновидностям SecurityContext. Может быть отличной отправной точкой для начинающих и шпаргалкой для опытных пользователей ;)

Спор о том, действительно ли контейнеры обеспечивают изоляцию, идёт давно, и автор поста Rory McCune считает, что баланс сейчас смещается: изоляция Docker-контейнеров всегда была слабее, чем у виртуальных машин из-за большой поверхности атаки ядра Linux, но раньше создание эксплойтов для побега из контейнера требовало редких навыков и много времени. Теперь же LLM-инструменты резко упрощают эту задачу. В качестве примера McCune взял свежую уязвимость локального повышения привилегий CIFSwitch (CVE-2026-46243) и просто передал модели блог-пост и готовый PoC.

За два часа и 13 долларов Claude Code самостоятельно собрал рабочий эксплойт для побега из контейнера. Ключевых условия два: достаточно «сговорчивая» модель (автор хвалит Opus 4.6, отмечая, что более поздние версии строже в наступательной безопасности) и цикл валидации, где модель реально тестирует код в одноразовых VM, чтобы не выдавать галлюцинации.

По мнению автора, на фоне волны свежих LPE-уязвимостей и такой лёгкости создания эксплойтов стоит пересмотреть надёжность стандартной изоляции контейнеров. Если вы запускаете недоверенные образы или есть риск исполнения кода внутри контейнера, нужно исходить из того, что атакующий сможет вырваться на хост. Это не значит отказаться от контейнеров — лишь сверить их использование со своей моделью угроз.

Вчера (7 июня) исполнилось 12 лет как Kubernetes увидел свет =)

По этому поводу вы можете:
1) Посмотреть документальный фильм про k8s
2) Почитать о ключевых датах в его развитии "The History of Kubernetes on a Timeline"

Как вы считаете 12 лет это много или мало для технологии/инструмента в IT ?

Inspektor Gadget — open source инструмент на базе eBPF для наблюдаемости в Kubernetes — прошёл первый независимый аудит безопасности. Аудит координировал OSTIF, финансировал CNCF, а проводила компания Shielder. Нашли всего три уязвимости, причём ни одной с критическим или высоким уровнем риска: две средних (command injection в сборке образов и DoS через переполнение eBPF ring buffer) и одну низкую (неэкранированные ANSI escape-последовательности в выводе терминала).

Самая интересная часть — тесты на обход «гаджетов»: исследователи проверяли, может ли скомпрометированный контейнер выполнять отслеживаемые операции, не вызывая событий. Они нашли шесть таких сценариев — например, использование новых системных вызовов вроде openat2 вместо openat, обход через io_uring и статически слинкованные библиотеки. Это наглядно показывает, что трассировка на уровне ядра — вечная игра в кошки-мышки: Linux эволюционирует, появляются новые syscalls, и eBPF-инструментам приходится постоянно за этим гнаться.

Исследование "Container Escape Paths Nobody Monitors: Abusing Linux Debug Interfaces" с Linux Security Summit рассматривает использование отладочных интерфейсов Linux для побега из контейнера на хост:
- ptrace,
- perf,
- eBPF,
- /proc и /sys файловая система.

Инструменты, которые разработчики используют ежедневно (strace, gdb, perf), являются мощным оружием в руках атакующего.

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

Безопасность контейнеров не ограничивается исправлением известных CVE. Основная угроза часто кроется в легитимных инструментах отладки Linux, которые остаются доступными из-за стандартных или небрежных настроек.

Большое спасибо всем докладчикам, партнерам и коллегам, участникам! Без вас не было бы нашей конференции. Увидимся через год ;)

Никита Хренов | Альфа-Банк, переходит к своему докладу - "Оператор Всевластия» для разработки распределенных систем и управления сетевой безопасностью"

📌 Трек Ингредиенты

Максим Василенко | Флант, переходит к своему докладу - "Контроль целостности в Kubernetes по-взрослому"

📌 Трек Ингредиенты

Валерий Кунавин | Ozon Банк, переходит к своему докладу - "Как не убить кластер и безопасность исключениями"

📌 Трек Рецепты

Андрей Орехов | Swordfish Security, переходит к своему докладу - "GitOps: мозг для политик безопасности"

📌 Трек Ингредиенты

Александр Алёхин | ecom.tech, переходит к своему докладу - "Validating Admission Policy замена Policy Engine?"

📌 Трек Ингредиенты

Андрей Слепых | Фобос-НТ и Анатолий Карпенко | LUNTRY, переходят к своему докладу - "ФСТЭК и контейнеры: от заявки до сертификата"

📌 Трек Рецепты

Дмитрий Селезнев | Инфосистемы Джет, переходит к своему докладу - "Фреймворк JCSF: zero to hero в контейнерах"

📌 Трек Рецепты

Максим Князев | К2 Кибербезопасность, переходит к своему докладу - "Контейнеры против майнеров или история по криптоджекинг в Kubernetes"

📌 Трек Ингредиенты

Алексей Костарев | Базальт переходит к своему докладу "Российская реализация ОС Talos"

📌Трек Ингредиенты

Александр Черток | Альфа-Банк, переходит к своему докладу - "SecK8S: от хаоса к системе"

📌 Трек Рецепты