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

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

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

Бесит ли вас 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.

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

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

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

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

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

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

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

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

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

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

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 можно ознакомиться тут и тут.

Не так давно отгремели крупнейшие мировые конференции по безопасности BlackHat LasVegas и DEFCON #33. В рамках последней проходит Cloud Village, которая посвящена аспектам облачной, контейнерной безопасности. Внимание нашей команды оттуда привлек доклад "Command and KubeCTL: Kubernetes Security for Pentesters and Defenders" от Mark 'antitree' Manning.

Автор выложил инструмент Pillage Registries (pilreg), который позволяет упростить множества пентестерских задач при работе с image registry. Отдельно в нем хочется отметить возможность/режим, который позволяет найти и достать файлы, которые с учетом манипуляций со слоями образа должны были быть удалены по мнению разработчика ;)

Также автор для одной из демонстрируемых атак использует пробэкдоренный vault, который через DNS сливает все секреты! Его код доступен тут, а основная магия происходит тут.

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

Заканчиваем эту неделю очередной уязвимостью в Kubernetes – CVE-2025-5187: Nodes can delete themselves by adding an OwnerReference.

Уязвимость заключается в том, что атакующий, сбежавший на Node, может воспользоваться kubeconfig от kubelet и обойти ограничение NodeRestrictionPlugin, выставив на Node OwnerReference с несуществующим объектом. Это в свою очередь заставит удалиться скомпрометированную Node и даст возможность навесить на новую Node taints или labels, что позволит атакующему контроллировать какие контейнеры будут запущены на воссозданном скомпрометированном узле.

Патч довольно простой и представляет из себя две строчки, в которых были добавлены проверки, запрещающие обновлять onwerReference от имени Node:

  if !apiequality.Semantic.DeepEqual(node.OwnerReferences, oldNode.OwnerReferences) {
   return admission.NewForbidden(a, fmt.Errorf("node %q is not allowed to modify ownerReferences", nodeName))
  }

Не смотря на кажущийся большой импакт на самом деле не всё так плохо.

1) Для эксплуатации уязвимости атакующий должен сбежать на Node.
2) Если у вас включен OwnerReferencesPermissionEnforcement plugin, то считайте, что вас эта уязвимость не аффектит.

Тем не менее, уязвимость получила оценку Medium (6.7) по CVSS.

Аффектит версии:

kube-apiserver: <= v1.31.11
kube-apiserver: <= v1.32.7
kube-apiserver: <= v1.33.3

Патчи доступны для:

kube-apiserver: >= v1.31.12
kube-apiserver: >= v1.32.8
kube-apiserver: >= v1.33.4

Мы уже неоднократно говорили, что командам SOC чрезвычайно важно собирать и анализировать Kubernetes Audit Log. Это мало кто делает ... А если и делают, то практически никто не обращает внимание на самый последний раздел ресурса Event под названием annotations. А там определенно есть к чему прикрутить правила детектирования:
- pod-security.kubernetes.io/exempt
- pod-security.kubernetes.io/enforce-policy
- pod-security.kubernetes.io/audit-violations
- authorization.k8s.io/decision
- authorization.k8s.io/reason
- validation.policy.admission.k8s.io/validation_failure

Обратите внимание что сработки Pod Security Admission (PSA) и Validating Admission Policy (VAP) можно ловить прям здесь.

Если вы не пропускаете наши выступления на конференциях и наши вебинары, то это для вас не новость) А так чтобы вы или ваш SOC был в теме, то следите за нашими исследованиями тут.

P.S. В ближайшее время в рамках SOC Tech и SOC Forum наша команда Luntry собирается представить новые работы в данном направлении.

Совсем недавно отгремела конференция Black Hat USA 2025, где было довольно много докладов из категории Cloud Security.

Один из докладов, на который стоит обратить внимание – ECS-cape – Hijacking IAM Privileges in Amazon ECS от Naor Haziz из Sweet Security.

Автор рассказывает про найденную им уязвимость, в Amazon ECS, которая позволяет задаче ECS с низкими привилегиями перехватывать учётные данные IAM других задач, запущенных в том же экземпляре контейнера, нарушая изоляцию задач.

Также автор представил PoC на Github. Со слайдами можно ознакомиться тут.

Kubernetes действительно объединяет не объединяемое, соединяет не соединяемое. И в итоге появляются такие проекты как KubeBuddy.

Это инструмент на PowerShell (!!!), который позволяет управлять и мониторить k8s кластера, генерируя вот такие красивые отчеты. Список возможностей правда интересный:
- Cluster Health Monitoring - проверки статусов node, resource, pod.
- Workload Analysis - идентификация проблем pods .
- Event Reporting - работа с Kubernetes events.
- RBAC & Security Checks - обнаружение излишних прав и мисконфигураций.
- Storage & Networking Insights - анализ persistent volumes, services и network policies.
- Customizable Thresholds - настройка уровней границ.
- HTML & Text Reports - генерация отчетов.
- AKS Best Practices Check - проверка Azure Kubernetes Service (AKS) кластеров на лучшие практики

Месяц назад мы рассказывали о разборе уязвимости CVE-2025-23266 в NVIDIA Container Toolkit от WIZ в статье NVIDIAScape - Critical NVIDIA AI Vulnerability: A Three-Line Container Escape in NVIDIA Container Toolkit (CVE-2025-23266). Однако в самой статье было немного глубоких технических подробностей. На днях нам попался детальный writeup об этой баге в двух частях.

В первой части автор показывает минимальный PoC для воспроизведения и поверхностно проходится по темам, которые непосредственно играют роль в уязвимости – Dynamic linker behavior, Docker alternate runtimes, CUDA Forward Compatibility и Container Device Interface.

Во второй части автор более детально углубляется в сам баг, а именно демонстрирует почему LD_PRELOAD заданный в контейнере передается на высоко привилегированный createContainer hook на хост и как это можно эксплуатировать.

Знакомясь с платформой контейнеризации Alauda Container Platform, наткнулись в её документации на раздел Security and Compliance, где есть замечательно оформленные по разделам политики безопасности для Kyverno. Для тех кто только начинает может быть хорошим стартом!

Продолжаем рассказывать про интересные доклады с Black Hat USA 2025. Сегодня затронем доклад Breaking Out of The AI Cage Pwning AI Providers with NVIDIA Vulnerabilities от Andres Riancho, Hillai Ben-Sasson и Ronen Shustin из WIZ.

Это доклад от исследователей, которые нашли CVE-2024-0132. В докладе они объясняют суть баги, показывают эксплойт, а затем приводят примеры инструментов и облачных провайдеров, которые были уязвимы к побегу из контейнера с помощью этой CVE.

Видео еще недоступно, но слайды можно посмотреть тут.

P.S – для тех кто еще не видел, вот тут можно прочитать наш разбор CVE-2024-0132.

В последней версии Docker Desktop под номером 4.44.3 была закрытая критическая уязвимость CVE-2025-9074, которая приводит к побегу из контейнера в Windows и Mac через SSRF! Linux версия не под угрозой =)

Для эксплуатации атакующий должен иметь возможность запустить свой вредоносный контейнер. Далее через SSRF может обращаться к Docker Engine (со всеми вытекающими последствиями), не требуя монтирования Docker сокета внутрь своего контейнера. Далее атакующий может создавать и работать с другими контейнерами на этом хосте и получить доступ к файловой системе хоста.

Уязвимость не затрагивает версию Linux, поскольку там используются именованные канала, а не TCP-сокет для взаимодействия с API Docker Engine.

Полные детали баги, POC и видео эксплуатации от авторов можно посмотреть тут.

Если вы используете образы от Bitnami – спешим сообщить, что у вас проблемы. Дело в том, что они решили перейти от свободно доступных образов bitnami к разделению на коммерчески поддерживаемые образы bitnamisecure и неподдерживаемые устаревшие образы bitnamilegacy.

Точные сроки неясны, поскольку в issue упоминается постепенное перемещение в legacy репозиторий, однако последствия начнут проявляться начиная с 28 августа 2025 года, поэтому очевидно, что компаниям, использующим эти образы, придется принять меры как можно быстрее.

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

SIG Multicluster (github, group) запустила опрос "User feedback Survey: Building Multi cluster Management and Monitoring tool" среди пользователей с опытом работы с мультикластерными системами для получения обратной связи для разработки инструментов управления и мониторинга мультикластерами. Если у вас есть желание повлиять на текущие и новые проекты, то сейчас как раз хороший момент. Среди проектов SIG Multicluster можно вспомнить:
- ClusterSet - для группировки кластеров (остальные проекты работают поверх этой абстракции)
- About API - для уникальной идентификации кластеров
- Multicluster Services API - для межкластерной публикации сервисов (об этом писали тут)
- Work API - для деплоя нагрузок на несколько кластеров
- ClusterProfile API - для упрощения обнаружения и управления кластерами

Вышла версия Kubernetes 1.34 под кодовым названием Of Wind & Will (O' WaW). Изменений предостаточно, но с точки зрения security мы бы хотели отметить несколько:

1) Built‑in Mutual TLS for Pods (Alpha). Pod теперь могут запрашивать краткосрочные сертификаты X.509 у Kubernetes API и использовать их для аутентификации по протоколу mTLS. Мейнтейнеры утверждают, что это обеспечит понятный и нативный подход к идентификации рабочих нагрузок внутри кластера без использования внешних инструментов или sidecar.

2) Fine‑Grained Anonymous API Endpoint Control (Stable). Вместо отключения анонимного доступа на уровне всего кластера теперь можно настроить его применение только к определённым путям (например, /healthz, /livez и /readyz). Это предотвращает overly permissive anonymous access, сохраняя при этом функциональность мониторинга и load balancers.

3) Short-Lived Pod-Scoped Tokens for ImagePull (Beta). Kubernetes теперь может использовать краткосрочные токены, автоматически генерируемые для каждого Pod, для доступа к private registry. Эти токены соответствуют требованиям OIDC и автоматически сменяются системой.

Со всеми обновлениями можно познакомиться прочитав заметку в официальном блоге Kubernetes.

То, что Gateway API заменит Ingress, это всего лишь вопрос времени. Не просто так же разрабатывали этого преемника)

И старые проекты также нужно будет мигрировать для получения всех преимуществ новой реализации. И тут поможет статья "How to easily migrate ingress to gateway API in Kubernetes" и код, упрощающий весь этот процесс.

В комментариях к посту можете рассказать запускаете ли вы уже новые проекты на Gateway API и переводите ли старые на него + какую реализацию выбрали для себя.

В Kubernetes есть проблема: встроенные Secret хранятся в etcd без надёжного шифрования и требуют особой осторожности при использовании.

Есть готовые популярные решения, вроде Vault, но автор статьи SecretForge — A Sidecar for Kubernetes Secrets решил пойти дальше и предлагает инструмент SecretForge — сайдкар, который сам преобразует секреты в удобный формат (.env или JSON) и обновляет их при изменениях. Это избавляет приложение от лишней логики и делает работу с секретами проще и безопаснее.

В статье есть также пример деплоя с использованием CSI Driver и SecretForge в одном Pod.