Сергей Канибор | LUNTRY. переходит к своему докладу - "Истории Kubernetes пентестов: путь через мисконфигурации"

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

Антон Баранов | ГК АСТРА, переходит к своему докладу - "Контейнеры под защитой PARSEC: пополнение в рядах AppArmor, SELinux"

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

Николай Панченко | Т-БАНК, переходит к своему докладу - "Зачем бизнесу нужна отдельная команда защиты Kubernetes?"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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