k8s (in)security

Всем, привет!

Мы продолжаем вам рассказывать про доклады с предстоящей конференции БеКон 2026! В этом году в техническом треке будет сразу 2 доклада про атаки и инциденты. Это:

1) "Истории Kubernetes пентестов: путь через мисконфигурации", Сергей Канибор (Luntry)
2) "Контейнеры против майнеров или история по криптоджекинг в Kubernetes", Князев Максим (К2 Кибербезопасность)

Напоминаем, что до конференции осталось всего 2 недели.

Небольшое, но важное изменение в Kubernetes 1.36: поле Service.spec.externalIPs официально объявлено deprecated. Эта функция существовала с первых версий Kubernetes и позволяла “привязывать” внешний IP к сервису, но все эти годы считалась небезопасной из-за риска MITM-атак и CVE-2020-8554.

Команда Kubernetes прямо говорит, что externalIPs — это “insecure by default”. В будущих релизах поддержку уберут полностью из kube-proxy, а пользователям предлагают мигрировать на LoadBalancer, NodePort или Gateway API.

Если вы не используете externalIPs, переживать не о чем. Но если используете — пора планировать миграцию: начиная с 1.36 – deprecated, а полное удаление ожидается примерно к версии 1.43.

Всем, привет!

Мы подводим итоги конкурса с призами в виде билетов на БеКон 2026! И так призы уходят к:

- @gecube
- @al_mark_work
- @iv_k4v
- @popepiusXIII

Каждый сценарий по своему интересен, уникален и подсвечивает разные проблемы. Поэтому мнения жюри сильно расходились и было решено сделать 4 победителя.

Всем, хороших выходных!

P.S. С победителями отдельно свяжемся и все передадим ;)

Постоянные и давние читатели нашего канала наверняка помнят наш доклад "Безопасность контейнеров и Kubernetes" c True Tech Day 2022 года и вебинар "Patch management не поможет, фиксики не спасут" в 2023, где мы рассказывали о том что vulnerability management все больше и больше теряет так сказать свою значимость для реальной защиты (не путать тем что он не нужен).

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

И вот недавно вышла еще одна очень любопытная заметка "The 90 day disclosure policy is dead" в которой еще ряд хороших аргументов и кейсов.

Такими темпами скоро требование/задача защиты от 0,5day и 0day будет уже не чем то заоблачным, только для избранных, а в порядке вещей для всех.

А как вы смотрите на это работу с уязвимостями в текущий реалиях 2026 года ?

Череда уязвимостей в ядре, приводящих к LPE и container escape продолжается.

На этот раз – fragnesia. Это новая LPE уязвимость из семейства Dirty Frag/Dirty Pipe, позволяющая локальному пользователю получить root через corruption page cache в подсистеме XFRM ESP-in-TCP. Эксплойт не требует race condition и работает как deterministic logic bug, что делает эксплуатацию особенно стабильной и опасной.

Интересно, что fragnesia появилась как побочный эффект одного из патчей для Dirty Frag. CVE пока не назначена, а фикс пока только в виде небольшого patchset, который ещё не успел попасть во все mainstream kernel releases.

P.S. Сегодня последний день подать свой вариант на конкурс и выиграть билет на нашу конференцию БеКон 2026.

На нашем сайте Luntry стали доступны материалы с выступления «Уязвимости в контейнерах и Kubernetes: правим, а не страдаем» (слайды, видео) с конференции CISO FORUM 2026 (Трек B. Когда атака — вопрос времен).

В рамках презентации были рассмотрены реактивный и проактивный подход по работе с уязвимостями. И все это на актуальной волне с гигантским количеством уязвимостей, их качеством описания, полнотой (проблемы с NIST NVD), приоритезацией и тем что AI (проекты типа XBOW, Claude Mythos) значительно ускоряют атакующего (как разработку 1day эксплоита по патчу, так и в нахождении 0day и автоматизации самой атаки).

Еще одним аргументом про изменение работы с уязвимостями (теперь как раньше уже не будет никогда) является последняя новость с легендарного соревнования pwn2own, где исследователи представляют свои 0day цепочки в самом популярном и желанном ПО. Новость в том что они просто не могут принять всех желающих на соревнование и отправляют отказы с просьбой самостоятельно с вендором разбираться в уязвимостях. В общем, buffer overflow по количеству 0day ....

P.S.Среди уязвимостей можно увидеть и уязвимости в стеке контейнеризации ...

Всем, привет!

Ну что начнем представлять и немного рассказывать про доклады БеКон 2026! начнем эту серию с докладов нового трека ("Рецепты"), который посвящён выстраиванию процессов и работе с людьми, командами. Этот трек в первую очередь будет интересен и полезен для С-level, `Leads,
которые продумывают и выстраивают все в компании.

В итоге мы отобрали следующие доклады:
- "Зачем бизнесу нужна отдельная команда защиты Kubernetes?", Николай Панченко
- "SecK8S: от хаоса к системе", Черток Александр (Альфа-Банк)
- "Фреймворк JCSF: zero to hero в контейнерах", Селезнев Дмитрий (Инфосистемы Джет)
- "ФСТЭК и контейнеры: от заявки до сертификата", Андрей Слепых и Анатолий Карпенко (Фобос-НТ и Luntry)
- "Как не убить кластер и безопасность исключениями", Кунавин Валерий (Озон Банк)

Продолжая освещать возможность эксплуатации CVE-2026-31431 (Copy Fail) для побега из контейнера, нельзя не упомянуть что и свежая CVE-2026-43284 (Dirty Frag) также открывает возможности для container escape.

На канале мы уже отмечали инструмент ctrsploit. В свежем обновлении там добавилось два новых модуля, позволяющих проэксплуатировать CVE-2026-31431 и CVE-2026-43284 в контексте container escape.

Всем, привет!

Нам нужно исправить одно недоразумение ... Мы до сих пор не разыграли билет(ы) на нашу конференцию БеКон 2026. Давайте это исправим ;)

Конкурс: "Что было дальше?".
Ситуация: Закрытый контур. Сертифицированная ОС, сертифицированный Kubernetes.
Задание: Придумайте почему и из-за чего там произошел серьезный инцидент информационной безопасности в кластере Kubernetes.
Критерий оценки :
- Реалистичность ситуации
- Оригинальность сюжета
- Технические детали инцидента
Итоги: 14 мая.

Всем хороших выходных!

В Kubernetes v1.36 появилась новая альфа фича — manifest-based admission control, которая переносит конфигурацию admission-политик из etcd в манифесты на стороне API сервера. Это решает архитектурную проблему, когда система безопасности хранилась в том же месте, которое она защищает.

Политики загружаются с диска ещё до старта API сервера, а не после. Это закрывает “startup gap”, когда кластер мог принимать запросы без применённых правил, а также снижает риск их удаления злоумышленником или проблем при падении etcd.

Более подробней об этом подходе и как он работает можно узнать из заметки "Kubernetes v1.36: Admission Policies That Can't Be Deleted".

Всем, привет!

Подготовка к нашей конференции БеКон 2026 идет полным ходом:
- доклады опубликованы,
- расписание верстается,
- партнеры подписываются,
- первый мерч готовится,
- стикерпак печатается!

Как всегда мы вложили душу в наш оригинальный стикерпак и ждет всех посетителей конференции.

До 2 июня уже не так-то и много времени осталось ;)

Для любителей Wazuh в их блог посте в этом году появилось 3 статья о его использовании при обеспечении безопасности Kubernetes:
- "Detecting Kubernetes attacks with Wazuh"
- "Detecting Kubernetes misconfigurations with KubeLinter and Wazuh"
- "Auditing Kubernetes with Wazuh"

На своей практике Wazuh мы не встречаем, но как бы то ни было в подобных статья всегда можно что-то подсмотреть под себя и переложить на вой стек, подход.

Ровно перед майскими праздниками выстрелила и сильно прошумела CVE-2026-31431. Уязвимость в ядре позволяет проэксплуатировать LPE (Local Privilege Escalation) на почти всех дистрибутивах с 2017 года. Все говорят об LPE, но мало кто отмечает, что эту же уязвимость можно использовать для побега из контейнера в Kubernetes.

Во-первых, об этом заявляют сами исследователи, которые обнаружили уязвимость. Обещают выпустить статью в блоге на этот счет (пока ещё не выпустили).

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

В качестве PoC советуем ознакомиться с репозиторием – Copy Fail (CVE-2026-31431) — Kubernetes Container Escape PoC.

P.S. Мы также подтверждаем применимость этого в реальных условиях: в рамках аудита Kubernetes кластера нам удалось успешно использовать эксплойт. Демонстрацию можно увидеть на видео из нашего тестового окружения.

Всем, привет!

До нашей конференции БеКон 2026 осталось чуть меньше месяца!

И наша команда и спикеры активно готовимся несмотря на праздники и длинные выходные =)
На сайте конференции вы уже можете увидеть список всех 15 докладов (+1 секретный), которые мы еще отдельно презентуем!

cpg - инструмент для генерации Cillium Network Policy с помощью данных от hubble relay.

Алгоритм работы инструмента чрезвычайно прост - анализ DROPPED потоков и формирование из этого новых изменений для Cillium Network Policy.

Можно настроить для:
- определенного namespace
- всех namespace
- с учетом L7
- offline генерации на базе записанного флоу

Еще бы hubble relay не ел ресурсы как конь, то было бы совсем замечательно, но Network Policy это уже точно стандарт де-факто для сетевой безопасности в Kubernetes. Если вы не используете Network Policy, то считайте нет у вас и сетевой безопасности.

PII-Shield — open-source инструмент для защиты логов и данных от утечки персональной информации прямо в Kubernetes . Он работает как sidecar контейнер, перехватывает stdout/stderr, находит секреты и чувствительные данные до того, как они попадут в лог-системы.

Сочетание Shannon Entropy для поиска неизвестных секретов (токены, API-ключи, пароли) и O(1) regex для точного детектирования известных паттернов снижает false positive и позволяет находить даже то, что не было заранее описано правилами.

PII-Shield работает полностью локально, без API вызовов наружу, с почти нулевой нагрузкой на GC. Интересный проект, чтобы попробовать безопасно коррелировать логи между сервисами, не раскрывая реальные данные.

Isopolicy — CLI инструмент от разработчиков Cilium для упрощения управления, проверки и тестирования Network Policy от Cilium в Kubernetes.

Основные функции:
- Статический анализ и проверка синтаксиса: Выполняет статический анализ политик для выявления распространенных ошибок конфигурации, таких как отсутствующие labels или непреднамеренные наложения.
- Моделирование политик: Включает команду моделирования, которая создает среду «что если». Это позволяет операторам предварительно оценить, как новые, измененные или удаленные политики повлияют на доступ к сети для разных идентификаторов или namespaces, не затрагивая работающий кластер.
- Историческая проверка: При подключении к Hubble Timescape может воспроизводить исторические потоки трафика, чтобы показать, как различные политики обрабатывали бы прошлый трафик, повышая общую «чистоту политик».
- Интеграция с GitOps: Может быть интегрирован в конвейеры CI/CD для автоматической проверки синтаксиса политик во время PR, блокируя мерджи, содержащие неподдерживаемые конструкции или очевидные ошибки.

Примеры использование можно посмотреть тут и тут.

KubeUser — это Kubernetes оператор для управления пользователями, доступами и kubeconfig без Keycloak, Dex и других тяжёлых IAM решений. Вместо ручной выдачи сертификатов и RBAC всё описывается декларативно через User CRD, а оператор сам создаёт доступы и готовый kubeconfig.

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

KubeUser использует стандартный Kubernetes CSR API, автоматически создаёт RoleBinding и ClusterRoleBinding, а kubeconfig сохраняет как Secret внутри кластера.

На прошлой неделе вышла новая версия Kubernetes 1.36 и в официальном блоге K8s сразу, друг за другом вышло 3 заметки посвящённые новым security улучшениям. Два из которых в данной версии и еще одно для предстоящей:
- "SELinux Volume Label Changes goes GA (and likely implications in v1.37)"
- "Kubernetes v1.36: User Namespaces in Kubernetes are finally GA"
- "Kubernetes v1.36: Fine-Grained Kubelet API Authorization Graduates to GA"

Такая концентрация и ориентир на развитие безопасности в Kubernetes не может не радовать)

Вышел Kubernetes 1.36 под кодовым названием Haru. И как обычно, мы рассказываем про улучшения и обновления с точки зрения security.

Главное «ломающее» изменение — постепенный отказ от externalIPs, так как механизм позволял перехватывать трафик и создавать MITM-атаки. Также усиливается валидация IP/CIDR и обновляется работа с сертификатами, что снижает риск некорректных конфигураций.

Среди новых security фич — constrained impersonation (ограничение прав при impersonation) и flagz endpoint для аудита параметров запуска компонентов. Они делают контроль доступа и проверку конфигурации кластера более прозрачными и безопасными по умолчанию.

Дополнительно в stable выходят user namespaces и более гранулярная авторизация Kubelet API, что помогает соблюдать принцип наименьших привилегий.