Мы начинаем публиковать доклады с программы БеКон 2025!

1) "Без секретов! Workload Identity Federation: безопасная аутентификация в облаке" (Дмитрий Лютов, Yandex Cloud)

Строить безопасность в облаке без механизма Workload Identity очень сложная задача. И если в западных облаках его наличие уже само собой разумеющееся, то в наших просторах далеко не все вообще знают что это за зверь такой. Задача этого доклада рассказать как опасно жить без него, как он устроен и как спасает.

2) "Неочевидные и непонятные моменты безопасности Kubernetes" (Дмитрий Евдокимов, Luntry)

Рабочее название доклада было "Ворчание старого деда про k8s security". А лейтмотивом стали вопросы на тренингах "Почему так?", "Почему до сих пор так?", "Почему не иначе?", "Доколе?" и т.д. В итоге, сформировался список таких моментов.

За детальным описанием можно обратиться сюда.

Исследователи из Trend Micro, обнаружившие CVE-2025-23359 (bypass после фикса CVE-2024-0132 о которой мы рассказывали тут) выпустил статью Incomplete NVIDIA Patch to CVE-2024-0132 Exposes AI Infrastructure and Data to Critical Risks, в которой раскрыли некоторые подробности.

Так например, они обнаружили некоторые проблемы производительности при использовании нескольких mount в контейнере, которые могут привести к DoS (о той же проблеме производительности независимо сообщили moby и NVIDIA):

1. Когда новый контейнер создается с несколькими маунтами, настроенными с помощью (bind-propagation=shared), устанавливаются несколько родительских/дочерних путей. Однако связанные записи не удаляются из таблицы монтирования Linux после завершения работы контейнера.

2. Это приводит к быстрому и неконтролируемому росту таблицы монтирования, исчерпывая доступные файловые дескрипторы (fd). В конце концов Docker не может создавать новые контейнеры из-за исчерпания fd.

3. Эта чрезмерно большая таблица монтирования приводит к серьезным проблемам с производительностью, не позволяя пользователям подключаться к хосту (например, через SSH).

Основываясь на этом были раскрыты некоторые детали для эксплуатации CVE-2025-23359 (но PoC так и не предоставили):

1. Злоумышленник создает два вредоносных образа контейнера, соединенных друг с другом с помощью символической ссылки volume.
2. Злоумышленник запускает образ на платформе жертвы напрямую или косвенно
3. Это позволяет злоумышленнику получить доступ к файловой системе хоста через состояние гонки.
4. Используя этот доступ, злоумышленник впоследствии может получить доступ к сокетам Container Runtime Unix для выполнения произвольных команд с привилегиями root, т. е. получить полный удаленный контроль над скомпрометированной системой.

Рады представить новую статью в блоге про то, как наше решение Luntry помогает справиться с нашумевшим IngressNightmare!

Помимо того, что мы детально разбираем сам процесс эксплуатации, так и показываем как с помощью Luntry можно защититься абсолютно на всех уровнях и так как умеем только мы! Обнаружить и предотвратить это с помощью:
- Сканирования образа
- Runtime защиты в гибридном формате
- Генерации NetworkPolicy

По сути можно было даже защититься (обнаружить и предотвратить), когда эти уязвимости были 0day!

P.S. Кстати не так давно мы обновили наш сайт и лого. Как вам ?)

P.S.S. Уже завтра состоится вебинар «Безопасность контейнеров и Kubernetes для специалистов анализа качества»

Мы продолжаем публиковать доклады с программы БеКон 2025!

1) "Расширение политик фильтрации трафика в Cilium" (Антон Баранов, ГК Астра)

Придумывать свои кастомные механизмы для сетевой безопасности в Kubernetes в обход CNI это прям признак дурного тона, не говоря уже о вреде для производительности и стабильности. В рамках же этого доклада вы узнаете как ребята все сделали по красоте: добавили свой eBPF код в Cilium, добавили в ресурс CiliumNetworkPolicy нужные поля, доработали Hubble.

2) "Чем собирать контейнеры если вы параноик?" (Михаил Кожуховский, Flowmaster)

Говоря про безопасность контейнеров, нельзя обходить стороной процесс сборки образов. Делая это не правильно, можно поплатиться компрометацией системы... При этом решений с каждым днем все больше - выбор не простой, но этот доклад вам поможет определиться.

За детальным описанием выступлений можно обратиться сюда.

В статье A Practical Approach to Keycloak Token Exchange: Converting External Tokens for Internal Use with Kubernetes and Istio рассматривается подход к настройке обмена токенами Keycloak в Kubernetes с помощью Istio.

Автор показывает как сконфигурировать CRD ресурс EnvoyFilter, в котором будет заложена Token Exchange Logic:

- Extract Authorization Header
- Make HTTP Call to Keycloak
- Inject Internal Token

В Блоге Istio есть статья "Istio: The Highest-Performance Solution for Network Security" с очень любопытными замерами! Сравнивалась производительность при шифровании трафика для ряда решений:
- Istio: 1.26 (prerelease), default settings
- Linkerd: edge-25.2.2, default settings
- Cilium: version v1.16.6 с kubeProxyReplacement=true
WireGuard uses encryption.type=wireguard
IPsec uses encryption.type=ipsec with the GCM-128-AES algorithm
Additionally, both modes were tested with all of the recommendations in Cilium’s tuning guide (including netkit, native routing mode, BIGTCP (for WireGuard; IPsec is incompatible), BPF masquerade, and BBR bandwidth manager).
- Calico: version v3.29.2 с calicoNetwork.linuxDataplane=BPF и wireguardEnabled=true
- Kindnet: version v1.8.5 с --ipsec-overlay=true.

Вышел Kubernetes v1.33: Octarine!

Это значит, что помимо новых фич, так же что уже 29 июня закончится поддержка версии 1.30.

А вы уже успели перекатиться на 30-ю серию или все еще на 20-й?)

Мы продолжаем публиковать доклады с программы БеКон 2025!

1) "Kyverno: Рецепты правильного приготовления" (Евгений Берендяев, Avito)

Kyverno на ряду с OPA Gatekeeper это два стандарта де-факто среди PolicyEngines. Если ни одного из них нет, то нет и безопасного и надежного кластера точно. Но и при их наличии их еще надо правильно готовить, так что бы они не валялись от кривых настроек и т.д. Здесь вы узнаете все лучшие практики по развёртыванию и поддержке Kyverno.

2) "Talos Linux в production: без SSH и с удовольствием" (Дмитрий Рыбалка, Lamoda Tech)

На первом БеКон у нас впервые прозвучало про OS Talos и видно как данная система набирает популярность на наших просторах. Но остается также и много вопрос как с такой измененной парадигмой обслуживания вообще жить. Автор как раз и поделится опытом и ответить на любые вопросы!

За детальным описанием выступлений можно обратиться сюда.

А еще появился официальный канал конференции. Рекомендуем подписаться, чтобы быть в курсе новостей, изменений, розыгрышей и тюд.

Начинаем этот день с очередной интересной заметки от Rory McCune – Cap or no cap.

Свой ресерч автор начал с allowPrivilegeEscalation поля в манифесте. Это достаточно интересно, поскольку на самом деле выставление этого значения не делает то, о чем говорит его название. Об этом мы рассказывали на канале в этом посте.

Продолжая эксперементировать c allowPrivilegeEscalation и добавлением capability, исследователь приходит к интересным выводам. Так например, если вы используете containerd, то:

- CAP_SYS_ADMIN (для работы нужно добавлять SYS_ADMIN) в манифесте позволяет задеплоиться
- allowPrivilegeEscalation: false + CAP_SYS_ADMIN – не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN – разрешает задеплоиться и добавляет capability
- добавление несуществующей capability LOREM – разрешает задеплоиться

Промежуточный итог: Kubernetes не проверяет, какие capability вы добавляете, и не генерирует ошибку, если вы добавляете недопустимую – он просто ничего не делает.

Далее автор продолжил свой эксперимент на cri-o:

- CAP_SYS_ADMIN – сработало
- SYS_ADMIN – сработало
- allowPrivilegeEscalation: false + CAP_SYS_ADMIN – не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN – разрешает задеплоиться и добавляет capability
- установка несуществующей capability привела к ошибке при создании контейнера

CRI-O обрабатывает это немного по-другому, позволяя работать обоим и выдавая ошибки при недопустимых capability.

Как мы уже неоднократно писали, поддержка User Namespaces в Kubernetes по умолчанию чрезвычайно важное событие в жизни k8s. И естественно, это заслужило отельной записи в официальном блоге Kubernetes под названием "Kubernetes v1.33: User Namespaces enabled by default!". Данная статья отвечает на все вопросы по данной теме, так что это просто MUST READ!

P.S. Для понимания проблематики рекомендуем освежить в памяти доклад "Linux user namespace в чертогах Kubernetes" с БеКон 2024.

Мы продолжаем публиковать доклады с программы БеКон 2025 (80%)!

1) "Как соответствовать требованиям ФСТЭК, если у вас контейнеры и кластеры" (Андрей Слепых, НТЦ "Фобос-НТ")

Для ФСТЭК России микросервисы больше не являются непонятными субстанциями и вообще к ним есть особый контроль и отношение (и кажется со временем его будет все больше). Ребята из испытательной лаборатории, которая активно участвует в развитии нормативной документации, расскажут как и что понимать из текущих документов/писем/приказов.

2) "Как спрятать Control Plane Kubernetes от любопытных глаз" (Каиржан Аубекеров, МТС Web Services)

В компаниях, предоставляющих облачные сервисы, командами поддержки, как правило, обслуживаются множество Kubernetes-кластеров, и их количество только растёт. И рано или поздно в компании появляется разумная мысль/потребность в формализации предоставления кластеров Kubernetes в облаке — услуге Kubernetes-as-a-Service (KaaS). По сути это возможность развернуть Managed Kubernetes в приватном облаке, или вообще сделать своё публичное облако. Разумной мыслью в подобных кластерах является скрыть от конечного пользователя Control-Plane, чтобы он не наворотил делов как с надежностью, так и с безопасностью. В данном докладе, автор расскажет о нескольких способах, как это можно сделать.

За детальным описанием выступлений можно обратиться сюда.

А еще появился официальный канал конференции. Рекомендуем подписаться, чтобы быть в курсе новостей, изменений, розыгрышей и т.д.

P.S. Билеты все утекают, а их ограниченное количество ... не тяните до последнего, чтобы потом пытаться их достать.

Kubectl Get Hacked – небольшая интересная заметка о том как можно получить RCE с помощью kubeconfig.

Если вы используете Managed Kubernetes в облачном провайдере, то наверняка замечали не совсем привычный kubeconfig файл, используемый для взаимодействия с кластером:

users:
- name: eks-user
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws
      args:
        - eks
        - get-token
        - --<cluster-name>
        - <your-cluster-name>
        - --region
        - <your-region>

Это довольно интересно, поскольку используя директиву exec мы можем выполнять любые команды на системе:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: <-- snip -->
    server: https://127.0.0.1:49249
  name: kind-exec-test
contexts:
- context:
    cluster: kind-exec-test
    user: kind-exec-test
  name: kind-exec-test
current-context: kind-exec-test
kind: Config
preferences: {}
users:
- name: kind-exec-test
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      args:
      - ./hacked
      command: touch

Что еще более интересно – в документации этот момент особо не выделяется. Только лишь предупреждение о том, что необходимо использовать kubeconfig из доверенных источников.

Сегодня публикуем последние два доклада нашей программы БеКон 2025!

1) "Тонкая настройка безопасности OS Linux для контейнеров: вредно и полезно" (Альмир Сарваров, Банк ДомРФ)

Что может быть хуже чем не безопасно настроенная система?! Это система настроенная без понимания, что, для чего и зачем. Ведь слепое следований лучшим практикам не всегда доводит до добра, тем более когда дело касается специализированных систем. Контейнерные системы это как раз специализированные системы. В рамках доклада разберемся как некоторые лучшие практики могут сделать только хуже.

2) "Чеклист безопасности ML-кластеров" (Николай Панченко, ТБанк)

Кругом AI хайп! А чем мы хуже?! У нас на конференции тоже будет про AI, но не сточки зрения безопасности моделей, ботов и т.д. ,а с точки зрения того как безопасно создать инфраструктуру, где это все готовиться и живет.

За детальным описанием выступлений можно обратиться сюда.

Скоро мы опубликуем и само расписание конференции. Но можно ориентироваться, что двери конференции откроются в 9:00, а закроются в 19:30. Можно сказать, что теперь у вас есть все чтобы спланировать посещение мероприятия. И успейте взять билет до 10 мая, так как будет вторая волна подорожания билетов.

Вчера мы опубликовали все доклады из программы нашей конференции БеКон 2025, а сегодня хотим разыграть на нее билеты =)

Для этого необходимо в комментариях к данному посту написать/прикрепить политику для любого PolicyEngine (Kyverno/OPA Gatekeeper/...), которая используется вами и отличается своей оригинальностью, необычностью ;) Тут хочется увидеть вашу креативность!

Итоги подведем 7 мая.

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

На прошедшей месяц назад конференции Black Hat Asia, в треке Arsenal, был представлен доклад KubeAPI-Inspector: discover the
secrets hidden in apis от Qiqi Xu (слайды тут).

Вместе с этим был опубликован инструмент, о котором идет речь в докладе – KubeAPI Inspector.

Автор описывает его как инструмент, специально разработанный для Kubernetes, и предназначенный для эффективного и автоматического обнаружения скрытых уязвимых API в кластерах.

Интересная хардкорная статья "Patch-Gapping the Google Container-Optimized OS for $0", как исследователь нашел патч для kernel баги и понял что патч еще не применен в дистрибутиве ОС для контейнерных окружений от Google. И все это в рамках соревнования kCTF, о котором мы уже неоднократно писали на канале 1,2,3,4 и т.д.

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

И если для атакующего это будет по сути 1day, то для защищающейся стороны это равносильно защите от 0day. Соответственно и подходы к защите в современном мире должны быть такие, что могут противостоять и 0day.

Ввиду этого так и популярны механизмы NetworkPolicy, AppArmor, которые помогают выстроить концепцию ZeroTrust.

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

Мы зафиналили и опубликовали расписание докладов - полную программу можно посмотреть тут.

Облако тегов по докладам можно представить так: Workload Identity, k8s, Cilium, eBPF, image builder, Kyverno, OS Talos, ФСТЭК, Control Plane, kernel, ML.

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

WIZ запустили очередную CTF – The Cloud Hunting Games CTF. На этот раз вам нужно расследовать инцидент в облаке. Задания базируются на распространенных TTP злоумышленников in the wild.

Попробовать порешать можно тут.

Сейчас с командой находимся в финальной стадии, написания статья про то как мы с помощью Luntry случайно поймали криптомайнер на просторах сети интернет.

В процессе этого мне вспомнилось как в самом начале (где-то в 2021), закладывания в решение функциональности observability, я рассказывал как можно с помощью этого делать свои sandbox, honeypots или даже deception system для контейнерных окружений! Но тогда, что-то всем дальше сканирования образов и не смотрели.

Далее на свет появился доклад "Безопасность Kubernetes: Фаза Deception" (слайды, видео) на конференции OFFZONE 2022. Он уже привлек больше внимания и даже люди делились потом как некоторых из тех техник внедрили у себя.

И вот в 2025 мы уже сами ITW ловим интересные кейсы в контейнерных окружениях, пишем правила детекта, IoC и т.д. и все с помощью своего детища и ни от чего не зависим!

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

Многие Kubernetes операторы после своей работы оставляют отчеты (например, Trivy operator или Kyverno), но до недавнего времени не было единого стандарта, по которому эти отчеты должны формироваться.

Инженеры из Kubernetes, вернее из Kubernetes Policy Working Group, предложили решение этой проблемы и создали проект OpenReports. Там они достаточно подробно описали API Reference со всеми полями, что должны содержатся в отчете согласно стандарту.

По словам разработчиков это должно решить такие проблемы как:

- Centralized Visibility
- Correlation and Analysis
- Automation and Auditing