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

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

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

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

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

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

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

Череда уязвимостей в ядре, приводящих к 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.

Постоянные и давние читатели нашего канала наверняка помнят наш доклад "Безопасность контейнеров и 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 года ?

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

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

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

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

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

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

Небольшое, но важное изменение в 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! В этом году в техническом треке будет сразу 2 доклада про атаки и инциденты. Это:

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

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

RBAC в Kubernetes часто становится последней линией защиты между скомпрометированным workload и полным захватом кластера. В докладе “RBAC Atlas: Mapping Real-World Kubernetes Permissions and Exposing Risky Projects” разбирается, насколько опасными могут быть избыточные permissions в популярных Kubernetes проектах.

Автор представил RBAC Atlas — каталог identities и overly permissive RBAC политик, найденных в реальных open source проектах. Доклад хорошо показывает, как даже небольшие ошибки в настройке прав доступа могут привести к повышению привилегий и компрометации всего кластера.

Продолжаем делиться интересными докладами по теме Kubernetes Security с прошедшей недавно конференции BSidesSF 2026. Доклад “Sandboxes, Seccomp, and Syscalls: Chasing Isolation in Kubernetes” от Mark Manning посвящён одной из самых сложных тем в Kubernetes — изоляции контейнеров и реальной безопасности sandbox-окружений.

Автор подробно разбирает, почему контейнеры сами по себе не являются полноценной границей безопасности, какие ограничения есть у seccomp и где проходит граница между виртуализацией и изоляцией. Особенно интересно, что в докладе рассматриваются не только способы защиты workload’ов, но и реальные сценарии обхода sandbox-механизмов.

Доклад будет полезен всем, кто работает с multi-tenant Kubernetes-кластерами и хочет лучше понимать риски container isolation.

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

Мы всей нашей командой с нетерпением ждем 2 июня, чтобы провести БеКон 2026 и порадовать вас морем интересных и полезных докладов, занимательных стендов наших партнеров и, конечно, же классного мерча, общения и знакомств на площадке! В этом году будет вот такая limited edition новинка ;)

Времени осталось меньше двух недель, так что успейте заполучить свой заветный тикет!

Kubesplaining — CLI-инструмент для анализа безопасности Kubernetes, написанный на Go. Он позиционируется как «Cloudsplaining для Kubernetes».

В отличие от большинства сканеров (Kubescape, Trivy, Polaris), которые ищут отдельные misconfigurations, данный инструмент строит граф privilege escalation и показывает реальные многошаговые цепочки атаки от любого непривилегированного субъекта до критических:
- cluster-admin / system:masters
- node-escape (привилегированные поды + hostPath)
- доступ к секретам в kube-system

Он использует BFS поиск по RBAC + состоянию подов и выдаёт полную цепочку с объяснениями, evidence и remediation.

Ключевые возможности:
- Модули (всего ~45 правил): RBAC (wildcard, impersonation, bind/escalate и т.д.), Pod Security, NetworkPolicy, Admission Webhooks, Secrets, ServiceAccounts, Least-Privilege (на основе audit logs).
- Поддержка живого кластера, snapshot (JSON) и отдельных манифестов.
- Отличные отчёты: интерактивный HTML, JSON, CSV, SARIF (для GitHub Code Scanning).
- CI-friendly: --baseline, --ci-mode, delta-анализ.
- Полностью offline-анализ после скачивания snapshot'а.
- Хорошая документация, примеры remediation (kubectl patch, Kyverno/Gatekeeper).

Здесь можно посмотреть демо отчет.

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

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

1) "Validating Admission Policy замена Policy Engine?", Александр Алёхин (Ecom Tech)
2) "GitOps: мозг для политик безопасности", Андрей Орехов (Swordfish)

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

CVE-2021-25740 — уязвимость в Kubernetes, которую фактически невозможно полностью исправить патчем (unpatchable), потому что проблема заложена в самой архитектуре Kubernetes. Атакующий с правами на изменение Endpoints или EndpointSlices может перенаправлять трафик туда, куда у него обычно нет доступа.

Главная опасность в том, что уязвимость позволяет обходить сетевые ограничения и использовать ingress/load balancer как “confused deputy” — доверенный компонент, который выполняет действия от имени злоумышленника. Это превращает даже ограниченные RBAC-права в потенциальный путь к lateral movement внутри кластера.

Авторы статьи делают акцент на том, что защититься можно только организационными мерами: жёстким RBAC, admission controllers и мониторингом изменений Endpoints/Services. Очередной хороший пример того, как некоторые проблемы Kubernetes нельзя «закрыть обновлением» — их приходится учитывать как часть threat model всей платформы.

Как мы все с вами хорошо знаем проект Ingress NGINX больше не получает ни развития, ни поддержки и только продолжает радовать пентесетров кучей классных уязвимостей (1,2,3).

При этом сообщество как-то старается продлить жизнь Ingress NGINX хотя бы доставляя ему security патчи. Мы уже писали про форк от Chainguard, но не им единым. Есть и другие.

И тут интересно в этой всей ситуации, то что кто делаем?! Кто живет без обновлений, кто-то переезжает на Gateway API, а вот кто-то живет на таких форках.

А как обстоят дела у вас?

В статье "Kubernetes security fundamentals: Secrets" автор разбирает управление секретами, выделяя три основные категории угроз: атаки на секреты в состоянии покоя (в etcd, на узлах или дисках), в процессе передачи и на API, которые их предоставляют.

Особое внимание стоит уделить двум нюансам: монтирование секретов как файлов в контейнер значительно безопаснее, чем передача их через переменные окружения, так как последние часто попадают в логи отладки. Также важно знать, что любой пользователь, который может создать pod в неймспейсе, автоматически получает доступ ко всем секретам в этом неймспейсе через механизмы kubelet.

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

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

Подключайтесь послезавтра в 19:00 к эфиру на тему "Как развитие контейнеров влияет на информационную безопасность" - будет полезно и не скучно ;)

Сегодня под прицелом нашего внимания небольшая статья "Beyond Container Capabilities: Understanding Linux Capability Sets". В данной статье достаточно коротко и ясно с визуализацией объясняют концепцию Capabilities.

Это важно понимать, чтобы осмысленно добавлять и забирать Capabilities в процессе следования принципу наименьших привилегий.

P.S. Мы на канале очень много писали про Capabilities и поэтому если вы хотите понять какие из них опасны, как это приводит к побегу из контейнера и к другим угрозам, то просто сделайте поиск по каналу по слову Capabilities ;)

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

Мы продолжаем (1,2,3) вам рассказывать про доклады с предстоящей конференции БеКон 2026! Без внимания не останется и безопасность хостовой ОС и ее механизмы для защиты контейнеров:

1) "Российская реализация ОС Talos", Алексей Костарев (Базальт)
2) "Контейнеры под защитой PARSEC: пополнение в рядах AppArmor, SELinux", Баранов Антон (ГК Астра)

И не забывайте, что на самой площадке при общении со спикерами и другими специалистами можно как углубляться в эти вопросы, так и обсуждать что в рамках доклада озвучено не было ;)

P.S. До конференции осталось меньше недели!

В статье «Why Kubernetes policy enforcement happens too late—and what to do about it» автор замечает, что большинство инцидентов в Kubernetes рождаются не в коде приложений, а в мисконфигурациях — отсутствующих лимитах ресурсов, слишком широких security context, неверных RBAC. Инструменты вроде OPA, Kyverno и Conftest хорошо ловят такие проблемы, но обычно делают это слишком поздно: в CI/CD или на admission контроллере, когда разработчик уже переключил контекст.

Автор предлагает сместить фокус с того, что проверяет политика, на то, где и когда срабатывает проверка — он называет это enforcement locus. Самый недооценённый момент — review-time: браузерные движки policy-as-code (например, GuardOn) парсят YAML прямо в diff пул-реквеста и показывают нарушения инлайн-комментариями, без CI и доступа к кластеру. Это не замена admission контроллеру, а дополнительный слой defense-in-depth, который ловит проблемы там, где их дешевле всего исправить.

В перспективе автор видит AI-агентов на том же review-time слое: они смогут не просто флагать нарушение, а объяснять контекст, предлагать готовый патч YAML прямо в PR и отличать настоящие ошибки от осознанных исключений в dev-окружении.

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

Мы продолжаем (1 ,2 ,3, 4) вам рассказывать про доклады с предстоящей конференции БеКон 2026 2 июня! Без внимания не останется ни одна тема, имеющая отношение к безопасности контейнеров, так что что безопасность на уровне оркестратора/кластера и сетевая безопасность:

1) "Контроль целостности в Kubernetes по взрослому", Максим Василенко (Флант)
2) "«Оператор Всевластия» для разработки распределенных систем и управления сетевой безопасностью", Хренов Никита (Альфа-Банк)
3) Секретный доклад (без публикации)

При этом секретный доклад продолжит тон прошлогоднего и даже разовьет эту тему ;)

P.S. Времени осталось совсем мало чтобы урвать свой билет!