k8s (in)security

02 June 2026 11:37

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

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

k8s (in)security

02 June 2026 11:37

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

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

k8s (in)security

02 June 2026 09:17

Дмитрий Рыбалка | Mindbox переходит к своему докладу - "SLSA — язык доверия: от CI до Runtime"

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

k8s (in)security

01 June 2026 07:02

Команда Kubernetes объявила, что 1 июня 2026 года Security Response Committee исправит несколько старых записей CVE в официальной базе. Проблема в том, что для ряда давних и до сих пор неисправленных уязвимостей в записях ошибочно указано поле «исправленная версия».

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

Практическое последствие стоит держать в голове: сканеры уязвимостей начнут находить эти CVE там, где раньше они не срабатывали. Так что после 1 июня в отчётах по безопасности могут появиться «новые» срабатывания — на самом деле речь о давно известных проблемах, просто корректно помеченных.

k8s (in)security

28 May 2026 07:00

В статье «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-окружении.

k8s (in)security

27 May 2026 07:23

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

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

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

k8s (in)security

26 May 2026 07:02

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

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

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

k8s (in)security

22 May 2026 07:03

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

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

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

k8s (in)security

21 May 2026 08:03

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

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

k8s (in)security

20 May 2026 07:01

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

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

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

k8s (in)security

18 May 2026 14:04

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

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

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

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

k8s (in)security

15 May 2026 14:01

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

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

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

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

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

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

k8s (in)security

14 May 2026 07:04

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

k8s (in)security

12 May 2026 14:05

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

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

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

k8s (in)security

08 May 2026 07:01

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

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

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

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

k8s (in)security

02 June 2026 11:37

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

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

k8s (in)security

02 June 2026 09:55

Максим Лебедев | Axiom JDK, переходит к своему докладу - "Бронебойный Java образ"

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

k8s (in)security

02 June 2026 07:12

Всем привет!

Сегодня 2 июня и это значит наступил долгожданный день конференции БеКон 2026! Таким образом сегодня будем рассказывать что происходит на конференции и, конечно, делится докладами с нее.

Также напомним, что одной из фишек БеКон является то, что слайды публикуются сразу как только докладчик выходит на сцену! А вопросы у докладчиков можно спрашивать как в приложении конференции, так и в комментариях ко слайдам.

Чтобы обо всем узнавать самым первым рекомендуем подписаться на канал конференции.

k8s (in)security

29 May 2026 08:25

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

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

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

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

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

k8s (in)security

27 May 2026 14:02

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

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

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

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

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

k8s (in)security

26 May 2026 14:53

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

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

k8s (in)security

25 May 2026 07:04

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

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

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

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

k8s (in)security

21 May 2026 14:05

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

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

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

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

k8s (in)security

20 May 2026 14:04

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

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

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

k8s (in)security

19 May 2026 07:00

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

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

k8s (in)security

18 May 2026 07:04

Небольшое, но важное изменение в 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.

k8s (in)security

15 May 2026 06:59

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

k8s (in)security

13 May 2026 07:38

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

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

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

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

k8s (in)security

12 May 2026 07:00

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

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

k8s (in)security

07 May 2026 07:01

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

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

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