В официальном блоге 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, то единственной уважительной причиной не быть на конференции может быть только невозможность быть в Москве в этот день.

Не так давно наш хороший товарищ и докладчик первого БеКон Дмитрий Путилин, хорошо известных в узких кругах Кубоводов, завел свой канал и выпустил невероятный материал Kubernetes The Hard Way на русском языке и с доскональным внимание к деталям.

Насколько детально там все рассматривается можно понять по прямому сравнению с Kubernetes The Hard Way от Kelsey Hightower.

В общем, это просто MUST HAVE материал для тех кто хочет реально понимать Kubernetes и стать крутым DevOps специалистом, а не ClickOps ;)

Почти месяц назад у Kyverno вышел новый релиз – 1.14.0. И это довольно значимый релиз, по скольку с него, можно сказать начинается новая веха в развитии этого Policy Engine. А именно – управление политиками стало более модульным, оптимизированным и мощным. Из крупных нововведений:

- два новых типа политики ValidatingPolicy и ImageValidatingPolicy
- улучшения и оптимизации при использовании CEL в политиках
- Policy exceptions теперь поддерживают CEL выражения
- улучшения kyverno CLI для валидации любых json-объектов

Более подробно об этом релизе и не только можно узнать в блоге Kyverno и в их документации.

На нашем сайте в раздел Исследований стало доступно видео и слайды выступления "Стандарт безопасности контейнеров NIST 800 190 в 2025 году" с конференции Deckhouse Conf 2025.

P.S. Получив обратную связь по данной работе, мы продолжили работать над картой и в последствии выложим ее в открытый доступ.

Совсем недавно, проходил очередной контест Pwn2Own. Примечательно, что организаторы ввели новую категорию AI с такими таргетами как:

- Chroma
- Postgres pgvector
- Redis
- Ollama
- NVIDIA Triton Inference Server
- NVIDIA Container Toolkit

Да, в списке есть тот самый NVIDIA Container Toolkit для которого мы готовили эксплойт и выпускали статью на этот счет!

Исследователи из WIZ в рамках Pwn2Own нашли еще один баг в этом тулките. Официально ни присвоения CVE, ни патча еще не последовало.

Как обычно, после раскрытия 0-day в ходе соревнования Pwn2Own у вендоров есть 90 дней на подготовку и выпуск патча для своих продуктов, прежде чем Trend Micro Zero Day Initiative опубликует технические подробности.

Отдельно стоит отметить, что категория Cloud-Native/Container осталась без находок.

Недавно наши друзья из исследовательской команды 4rays у себя на канале опубликовали пост про "Безопасность локальных docker-реестров через механизм нотификаций" про отслеживание подозрительной активности в локальных docker-реестрах.

Честно мы (да думаю и многие) в данном направлении ранее даже не думали. В основном тут все сосредоточенны на:
- Вопросах аутентификации и авторизации
- Безопасной контролируемой сборке
- Registry Staging
- Защищенном registry
- Подписи образов
- Запуску только из разрешенного registry
- Запрет на push из prod кластера
- и т.д.

И действительно дополнительным уровнем можно еще добавить мониторинг за операциями работы с образами и их слоями. На пример, когда:
- используется не типичный user-agent
- работа проходит со странных адресов
- работа идет в нерабочее или не типичное время для данной операции
- имя образа не соответствует шаблону именования вашей компании

Кто-нибудь уже так делает или смотрел в эту сторону?

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

Если вы вчера пытались купить билет и у вас уже это не получилось, то спешим сообщить , что сегодня мы добавили еще небольшую партию билетов ;)

Наверняка, если вы проводите пентесты, то попав в изолированное и/или non-root окружение, в первую очередь вы попытаетесь поднять себе привилегии. Скорее всего для этого вы будете использовать известный всем LinPEAS (он кстати тоже частично может помочь, если вы оказались в докер контейнере или Kubernetes Pod).

Однако, ребята из Hacktrics пошли дальше и сделали набор скриптов – CloudPEASS. Эта штука представляет из себя набор python скриптов для поднятия привилегий в облачных окружениях GCP, AWS и Azure.

Так что, если проводите пентесты в облаках, CloudPEASS – must have!

BLAFS - инструмент для исключения из образов всего лишнего, не нужного, постороннего для оптимизации размера, уменьшения поверхности атаки и уменьшения количества CVE в образе.

Подробнее об инструменте можно узнать из его пейпера "The Cure is in the Cause: A Filesystem for Container Debloating".

В документе инструмент называется BAFFS (Bloat Aware File-System), но авторы потом переименовали и выложили по другому адресу. Для своей работы инструмент конвертирует образ контейнера в новый вид с новой ФС и уже с помощью нее понимает, что в образе не используется и можно выкинуть. Естественно для профилирования вам нужно запустить хорошие, полноценные unit tests/integration tests. Иначе профилирование будет не точное.

Идейно напоминает инструмент Slim/SlimToolKit/Mint (о нем писали тут), и о с ним также проводится сравнение. Классно что новая предложенная техника также может быть использована вместе с lazy load.

Казалось – через kubectl debug можно довольно легко сбежать на Node (если на это есть соответствующие права):

kubectl debug node/desktop-control-plane -it --image=busybox
chroot /host

Однако, при взаимодействии с container runtime сокетом, можно получить такие ошибки:

ctr: failed to unmount /tmp/containerd-mount2094132404: operation not permitted: failed to mount /tmp/containerd-mount2094132404: operation not permitted

Всё дело в том, что ephemeral container запускается с недостаточными привилегиями. И это можно исправить просто указав флаг --profile:

kubectl debug node/desktop-control-plane -it --image=busybox --profile=sysadmin

В этом KEP есть подробная информация о том какие возможности дает тот или иной профиль. Более подробно эту тему поднял Rory McCune у себя в статье – Kubernetes Debug Profiles.

P.S – также для kubectl debug можно передать параметр -n и тогда debug контейнер запустится в указанном неймспейсе. Особенно удобно поднимать его в kube-system, поскольку имя Pod будет что-то вроде node-debugger-desktop-control-plane-9gd7q и не привлечет много внимания, чего порой нужно добиться на пентесте.