Как мы уже неоднократно писали, поддержка 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

В официальном блоге Kubernetes появилась заметка "Kubernetes v1.33: From Secrets to Service Accounts: Kubernetes Image Pulls Evolved" про новую фичу версии 1.33.

Если описать данное улучшение одним предложением, то: "This enhancement allows credential providers to use pod-specific service account tokens to obtain registry credentials, which kubelet can then use for image pulls — eliminating the need for long-lived image pull secrets."

И тут (на мой взгляд) мы встречаем впервые упоминание workload identity не в тематике облачных провайдеров.

В итоге это дает least privilege и ephemeral authentication.

ServiceAccountTokenForKubeletCredentialProviders feature gate пока находиться в alpha, то авторы планируют его перевести в beta уже в 1.34.

Следить за развитием данной фичи можно в KEP-4412.

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

Подведем итоги конкурса, который мы не давно проводили. Проходка на конференцию уходит к @gakuseii_1 за его хитрую политику предоставления привилегированного доступа на основании как группы пользователей, так и самих сервисов. Хотя вариант с запретом деплоям по пятницам нам тоже очень сильно понравился. И подумали,а почему бы и не дать еще одну проходку @TheAnastasi )

Есть еще вариант выиграть хорошую скидку в рамках конкурса на канале конференции БеКон.

Так количество доступных билетов очень быстро уменьшается - не тяните до последнего.

На канале мы уже как-то рассказывали про Aggregate Roles в Kubernetes (1, 2), но хочется ещё раз напомнить о таком мощном механизме.

В статье Simplifying RBAC Extension in Kubernetes: Leveraging Aggregate ClusterRoles автор рассказывает как объединить несколько ролей для динамического контроля доступа, упростить управление разрешениями и применять изменения декларативно, используя лучшие практики.

Если запустить контейнер в Kubernetes и ничего не делать с capabilities (это подмножество привилегий, которые обычно предоставляются root), то в итоге у контейнера они все равно будут. Это так называемые Default Capabilities:
- cap_chown - Разрешает изменение владельца файлов.
- cap_dac_override - Разрешает доступ к файлам, игнорируя права.
- cap_fowner - Разрешает изменение владельца файлов.
- cap_fsetid - Разрешает установку битов setuid и setgid.
- cap_kill - Разрешает отправку сигналов процессам.
- cap_setgid - Разрешает изменение группы.
- cap_setuid - Разрешает изменение пользователя.
- cap_setpcap - Разрешает установку собственных способностей.
- cap_net_bind_service - Разрешает привязку к привилегированным портам (ниже 1024).
- cap_net_raw - Разрешает использование сырых сокетов.
- cap_sys_chroot - Разрешает изменение корневой директории.
- cap_mknod - Разрешает создание специальных файлов.
- cap_audit_write - Разрешает запись в журнал аудита ядра.
- cap_setfcap - Разрешает установку способностей для файлов.

Поэтому всегда не забывайте прописывать в настройках рабочих нагрузок:

securityContext:
  capabilities:
    drop:
    - ALL

Это спокойно работает для 99.9% любых бизнес микросервисов. С инфраструктурными сервисами разговор уже отдельный, но и там необходимо следовать принципу наименьших привилегий.

Если вы хотите более подробно погрузиться в работу Static Pods и порождающихся вместе с ними Mirror Pods, то статья Kubelet Mirror Pod Behaviours точно для вас.

В статье автор рассматривает два интересных поведения Mirror Pods:

1) Mirror Pods обходят любые Admission Controls, т.к деплоятся в обход Kube API. Хоть этого не видно через kubectl или в логах kubelet, тем не менее успешный запуск контейнера можно увидеть обратившись напрямую к container runtime socket.

2) Mirror Pods возможно создавать в несуществующих namespaces. Не смотря на то, что нам вернутся ошибки, контейнер будет создан. Это также можно увидеть обратившись напрямую к container runtime socket.

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

До БеКон 2025 осталось ровно 2 недели.

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

В этом году в рамках выставки вы можете познакомиться и пообщаться с:
- Разработчиками 4-х платформ контейнеризации - всё запустить
- Крутыми профессионалами в области DevSecOps - всё просканировать, проанализировать, проконтролировать
- Разработчиками 4-х платформ ASOC/ASMP - всё затриажить, избавиться от дубликатов и проконтролировать исправление

Так что если вы строите современную инфраструктуры с ориентиром на безопасность, то за 1 день можно посмотреть абсолютно все: от IT-ландшафта, до безопасности оркестратора с обработкой уязвимостей.

Все это полезно ИТ и ИБ департаментам.

P.S. Если вы у нас раньше не были, то имейте ввиду. Последние 2 недели это самая жаркая пора по покупке билетов. Так что если вы не успеете их купить, то пеняйте на себя. У нас их ограниченное количество.

У нас в блоге вышла новая замечательная статья "Случайный ханипот: как мы обнаружили криптомайнер в контейнере с помощью Luntry".

Из нее вы узнаете как Luntry может выполнять роль sandbox, deception system, honeypot и помочь ловить даже неизвестные атаки и вредоносный код, не имея никаких заготовленных правил, сигнатур и т.д.

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

На канале в предыдущих постах мы несколько раз затрагивали важность использования User Namespace в Kubernetes.

Сегодня хотим поделиться еще одним ресурсом, на котором еще 6 (!) лет назад обсуждали проблемы и критиковали использование данного механизма.

Если вы еще не выставляете

spec:
  hostUsers: false

для своих нагрузок, то вероятно пришла пора это сделать.

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

Очень внимательные люди в программе на сайте нашей конференции БеКон 2025 заметили упоминание Секретного доклада на закрытии конференции. И полетели вопросы, что это за доклад)

Раскрывать секрет мы сейчас не будем, но правда будет 11-й доклад и он будет без записи и без публикации материалов.

P.S. Билетов осталось совсем мало. И на наш взгляд если вы занимаетесь DevSecOps, безопасностью контейнеров, кластеров Kubernetes, то единственной уважительной причиной не быть на конференции может быть только невозможность быть в Москве в этот день.