k8s (in)security

11 августа вышла версия Istio 1.27. И вот что изменилось:

- добавлена поддержка API Gateway для управления ingress traffic
- поддержка мультикластерной установки в ambient mode перешла в альфа
- CRL теперь доступен для пользователей, подключившим собственный центр сертификации
- новый API ListenerSets позволяет определить reusable set of listeners, которые будут привязаны к ресурсу Gateway
- Istio теперь поддерживает native nftables backend в Sidecar mode

Со всеми Change и Upgrade Notes можно ознакомиться тут и тут.

Прямо монументальная статья с очень говорящим названием "From Linux Primitives to Kubernetes Security Contexts". В данном материале подробно рассматривается как и что работает в SecurityContext. Просто MUST READ для всех начинающих)

P.S. Единственный момент, который почему-то не упомянули, говоря о проблеме root пользователей и о механизме user namespace это опцию hostUsers. Может из-за того что она находится за рамками SecurityContext ...

Начинаем эту неделю со статьи – Complete Guide: Using Kubernetes Secrets Store CSI Driver with HashiCorp Vault.

В этом гайде вы узнаете, как интегрировать HashiCorp Vault с Kubernetes Secrets CSI Driver, настроить аутентификацию Kubernetes и создать ресурсы SecretProviderClass для безопасного управления секретами.

Полезная шпаргалка по различным Kubernetes специфичным логам.

Чтобы вы еще сюда добавили?

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

В конце прошлого года мы уже рассказывали про DVKA. Сейчас проект получил обновление, там добавили новую третью лабу.

Новый challenge предлагает проэксплуатировать следующую цепочку уязвимостей для полного захвата Kubernetes кластера: RCE в веб приложении ⭢ CVE-2025-1974 в ingress nginx (Ingress Nightmare) ⭢ получение доступа к секретам во всём кластере ⭢ получение секрета от Argo CD ⭢ деплой привилегированного контейнера на мастер ноду через Argo CD.

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

Бесит ли вас YAML при работе с манифестами Kubernetes?
Вы когда-нибудь слышали про KYAML?

Так вот KYAML это диалект/подмножество YAML для Kubernetes, и оно будет доступно с Kubernetes 1.34, что выйдет в конце августа.
Стоит отметить:
- KYAML можно передавать на вход любой версии kubectl
- С kubectl v1.34 можно получить выдачу в KYAML формате (kubectl get -o kyaml …)
- Очень похож на JSON, но есть комментарии
- Любой YAML совместимый парсер поймет и KYAML
- У разработчиков нет планов полностью на него переходить

Подробнее о KYAML можно узнать из KEP-5295.

Вышла новая версия Kyverno – 1.15, и там случилось довольно много изменений.

В новом релизе мы видим всё более масштабное слияние с ValidatingAdmissionPolicy (VAP), а также более мощную поддержку CEL выражений. Таким образом мы имеем 3 новых ресурса – MutatingPolicy, GeneratingPolicy и DeletingPolicy. Разработчики заявляют, что замеры производительности выявили значительные улучшения при использовании ValidatingPolicy по сравнению с традиционным ClusterPolicy на политиках PSS.

Также из интересного, в новой версии Kyverno добавлена поддержка новой OpenReports API group (openreports.io) для PolicyReport ресурса. Легаси API group (wgpolicyk8s.io) будет депрекейтнута в следующих релизах.

k8s (in)security pinned a photo

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

Начинаем неделю с публикации всех материалов с нашей конференции по БЕзопасности КОНтейнеров - БеКон 2025.

- Слайды
- Видеозаписи
- Фотографии
- Итоговый ролик

Еще раз спасибо всем докладчикам, участникам, партнерам и команде организаторов!

Мы уже работаем над БеКон 2026 - смотрите за новостями, пишите по поводу идей выступлений (мы их уже можем начать обсуждать и вместе прорабатывать).

P.S. Уже запланировано несколько классных нововведений ;)

Сегодня хотим продолжить освещать тематику eBPF, а именно расскажем про новый C2 агент – RingReaper, который работает полностью (ну почти) на вызовах io_uring и обходит классические EDR.

RingReaper заменяет такие вызовы, как read, write, recv, send, connect и другие, асинхронными операциями ввода-вывода (io_uring_prep_*), снижая риск перехватов и трассировки событий, которые обычно стандартизированы для продуктов безопасности.

Однако, некоторые функции RingReaper по-прежнему полагаются на традиционные системные вызовы, такие как чтение каталогов (opendir, readdir) или разрешение символических ссылок (readlink), поскольку io_uring пока не полностью поддерживает эти типы операций. Тем не менее, во время тестов автора эти вызовы не вызывали оповещений на тестируемых EDR именно потому, что они выходили за пределы контролируемых сетевых путей ввода-вывода.

Более подробно о своем инструменте и подходе автор рассказал в статье Red Team Tactics: Evading EDR on Linux with io_uring

Если вы думаете, что тема совместимости образов контейнеров крутиться чисто вокруг Open Container Initiative (OCI), то это было так до недавнего времени, а сейчас еще появилась такая штука как Node Feature Discovery (NFD). Подробнее об этом можно узнать из статьи "Image Compatibility In Cloud Native Environments".

А если кратко, то данный проект призван помочь определить совместимость образа с конкретной конфигурацией хостовой ОС. Ведь Nodes в кластере могут отличаться друг от друга:
- Драйверами
- Библиотеками и специализированным ПО
- Фичами ядра

Цели данной спецификации совместимости:
- Определение структурированного способа выражения совместимости в манифестах образов OCI.
- Поддержка спецификации совместимости наряду с образами контейнеров в реестрах образов.
- Разрешение автоматической проверки совместимости перед планированием контейнеров.

В первую очередь это будет полезно для отраслей телекоммуникации, высокопроизводительных вычислений (HPC) и искусственного интеллекта (AI).

P.S. Сегодня можно c нашей командой пообщаться лично на Kubernetes Community Day или смотрите в онлайне ;)

Сегодня хотим рассказать об инструменте fake-nvidia, который позволяет сэмулировать видеокарту и "пробросить" её в контейнер. Драйвер подгружается как модуль ядра, в результате чего мы получаем фейковую NVIDIA Tesla T4 прямо в контейнере.

Инструмент может быть полезен для воспроизведения, отладки (или поиске новых багов) в Nvidia Container Toolkit, например CVE-2024-0132 или свежей CVE-2025-23266. Не всегда есть возможность использовать дорогостоящие GPU (или их просто может не быть в наличии), однако такой инструмент без проблем решит эту проблему.

1−2 августа 2025 в Перми в рамках конференции Ural Digital Weekend наша команда Luntry в лице Анатолия Карпенко представит доклад " Готовим сервис к безопасной работе в Kubernetes: рекомендации для разработчиков (и не только)".

В докладе рассмотрим нюансы подготовки приложения и окружения для работы в проде. На примерах разберем, что безопасность приложения начинается в IDE разработчика и не заканчивается передачей в отдел эксплуатации/DevOps/клиенту.

В 2023 году в рамках этой же конференции мы делали доклад “Создание Network Policy в Kubernetes: ключевые аспекты и рекомендации для разработчиков”.

В общем продолжаем рассказывать для разработчиков про безопасность контейнеров в Kubernetes.

Если вы по какой-либо причине задумывались и задавались вопросом как обстоят дела с постквантовой криптографией (PQC) в экосистеме Kubernetes, то статья "Post-Quantum Cryptography in Kubernetes" в официальном блоге Kubernetes как раз для вас ;)

В тексте рассказывается, что Kubernetes версии 1.33 уже по умолчанию поддерживает гибридный постквантовый обмен ключами (X25519MLKEM768) благодаря интеграции Go 1.24.

При этом важно понимать и подводные камни, такие как несоответствие версий Go, приводящее к деградации, и проблеме с размерами пакетов Client Hello.

Но PQC для цифровых подписей и иерархий сертификатов все еще находится на ранних стадиях разработки и внедрения общего использования.

Исследователь Mark 'Antitree' Manning продолжает делиться с сообществом полезными инструментами в области Container Security. В наших прошлых постах (1, 2) мы рассказывали о его заметках и докладе, касательно использования Seccomp профилей в Kubernetes, однако автор решил пойти дальше и представил ресурс https://seccompare.com.

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

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

Более подробно о ресурсе автор рассказал в своей заметке – Introducing Seccompare.com: Seccomp Diffs For Containers.

В пятницу как обычно хочется чего-то легко, непринуждённого и у нас есть сегодня такой контент.

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

Сегодняшний проект Neko это self-hosted виртуальный браузер (и не только), который запущен в Docker и использует WebRTC.

Все это к тому же о чем мы писали в контексте Virtual Desktop Infrastructure (VDI) систем!

P.S. Нет машины - нет поверхности атаки ;)

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

В глаза, конечно, сразу бросается цифра 0,7%.
Это процент уязвимостей что были замечены в атаках за все время по отношению ко всем уязвимостям в базе CVE.

Обязательно рекомендуем посмотреть страничку с общей статистикой - там много интересного.

Как мы уже говорили раньше в наших постах, по нашему опыту анализа защищенности контейнерных сред, уязвимостями мы редко пользуемся - чаще всего это проблемы или отсутствие контроля YAMLs, отсутствие принципа наименьших привилегий в RBAC, отсутствие микросегментации с помощью NetworkPolicy, бесконтрольное использование образов контейнеров.

Если вам по каким либо причинам нужны все JSON схемы для всех версий объектов во всех версиях Kubernetes, то данный проект это все в себе и содержит!

Это может быть полезно, на пример, при написании своего собственного валидатора Kubernetes ресурсов ;) А такие инструменты как Kubeconform и Kubeval, как раз этот проект и используют у себя под капотом.

Единственное помните, что это позволяет проверить только соответствие OpenAPI Schema, но не гарантирует соответствие Server Side Field Validation! Ресурс на корректность в Kubernetes проверяется в 2-х местах.

31 июля в рамках Kubernetes Community Day наша команда Luntry поучаствует в программе с докладом "Ретроспектива уязвимостей Kubernetes" от Сергея Канибора и в круглом столе на тему "Что в K8s можно закрыть security by design, а что наложенной безопасностью?" с Дмитрием Евдокимовым.

Продолжаем нести светлое, прекрасное, безопасное в этот Мир)

Недавно из одного репоста довелось узнать про такую новую метрику как LEV (Likely Exploited Vulnerabilities, вероятно эксплуатируемые уязвимости). Если совсем кратко и не дублировать пост и текст самого документа NIST CSWP 41: "Likely Exploited Vulnerabilities: A Proposed Metric for Vulnerability Exploitation Probability", то она призвана повысить эффективность и экономичность усилий по устранению уязвимостей. При этом она не отменяет Exploit Prediction Scoring System (EPSS) и Known Exploited Vulnerabilities (KEV), а дополняет и использует первую метрику в процессе вычисления (даже инструмент уже есть).

И тут бы хотелось развенчать 3 утопичные мысли/плана:
1) закрывать абсолютно все уязвимости
2) закрывать только самое критичные уязвимости
3) закрывать только известные уязвимости

Реальность намного суровее и все сталкиваются с количественными и временными ограничениями, доступными ресурсами, кадрами, бюджетами, точностью инструментов, возможностями и мастерством атакующих, наличие 0day и 0,5day уязвимостей. Так или иначе любой из этих планов рушится на том или ином аспекте. А нам нужно систему делать безопасной (на деле, а не на бумаге).

Поэтому намного выгоднее вкладываться не в закрытие конкретной уязвимости (это лишь частный случай), а в закрытие целого класса, вектора через харденинги, митигейшены. У контейнеров в Kubernetes как мы недавно обсуждали таких механизмов предостаточно.