k8s (in)security

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

30 сентября в 11:00 наша команда Luntry проведет вебинар «Безопасность контейнеров и Kubernetes для DevSecOps специалистов».

Это продолжение серии вебинаров о безопасности контейнеров и Kubernetes для:
- CISO
- Cпециалистов SOC
- Cпециалистов анализа качества

Здесь мы как обычно рассмотрим основные задачи и проблематику для специалистов данного направления. Посмотрим OpenSource и его возможности. На пример, поговорим почему Trivy и решения на его базе, не лучший выбор для системного подхода к безопасности в рамках компании. И, конечно, представим наше виденье на правильный подход к организации безопасности образов и покажем нашу новую фичу Image Security Gate.

Зарегистрироваться на вебинар можно тут.

P.S. Для каких категорий специалистов вы бы еще хотели послушать подобные вебинары?

Сегодня мы вам рекомендуем ознакомиться со статьей "Hot-Patching Pods in Kubernetes 1.33: What Breaks, What Works, and How We’re Making It Usable".

Как несложно догадаться материал посвящён InPlacePodVerticalScaling feature gate, о которой мы писали еще в рамках "KEP-1287: In-place Update of Pod Resources" в 2022 году, и которая появилась в статусе alpha в версии 1.27. А в 1.33 уже включенной по умолчанию. Также стоит в рамках этого ознакомиться со статьей из официального блога "Kubernetes v1.33: In-Place Pod Resize Graduated to Beta".

Из статьи вы узнаете:
- Без заранее установленных requests и limits у вас ничего не выйдет
- Создание патча не гарантирует его применение - проверяйте .status.containers[].resources
- Стоит не забывать про добавление resources.resizePolicy
- В RBAC нужно право PATCH на /resize subresource
- Где можно получить с новой фичи преимущества
- Как это все живет с HPA и VPA

Очередная critical уязвимость с оценкой 10/10 по CVSS в Argo CD – Argo CD's Project API Token Exposes Repository Credentials.

Атакующий воспользовавшись токеном с доступами на проект, может узнать критичные данные, такие как креды для подключения к репозиториям. Для этого ему нужен токен с такими правами на проект:

p, proj:myProject:project-automation-role, applications, sync, myProject/*, allow
p, proj:myProject:project-automation-role, applications, action/argoproj.io/Rollout/*, myProject/*, allow
p, proj:myProject:project-automation-role, applications, get, myProject/*, allow

И один запрос в API:

curl -sH "Authorization: Bearer $ARGOCD_API_TOKEN" \
  "https://argocd.example.com/api/v1/projects/myProject/detailed"

Исправления доступны для версий Argo CD – 2.13.9, 2.14.16, 3.0.14, 3.1.2.

Самое время пропатчиться и проверить не закешировался ли где то токен - по дефолту его можно найти в ~/.config/argocd/config.

KubernetesEnumerationTool это инструмент на PowerShell для анализа Kubernetes кластеров на различные проверки:

- Namespace Actions - позволяет получать пространства имен, в которых вы можете выполнять определенные действия
- Secrets Discovery - позволяет получать доступ к секретам Kubernetes в различных пространствах имен
- Release Information - позволяет определять информацию о релизах
- Image Updates - позволяет идентифицировать наличие более новых образов
- Node Exploitation - позволяет попадать на хост и получать с него информацию (фокусируется на Azure)
- Network Policy Check - позволяет проверять настройки сетевой политики Kubernetes
- Best Practice Validation - позволяет обеспечивать соблюдение подами лучших практик
- DoS Testing - позволяет проводить тест отказа в обслуживании Kubernetes

P.S. Есть идеи почему последнее время все больше инструментов для K8s появляется на PowerShell ? Хотя в будущих планах есть пункт "Rewriting in Go to enhance performance." =)

В Kubernetes v1.34 появилась бета-фича — файл .kuberc, который позволяет персонализировать kubectl. Можно задавать дефолтные параметры (например, чтобы kubectl apply всегда работал в server-side режиме или delete спрашивал подтверждение).

Более того — можно заводить алиасы: вместо длинной команды kubectl get pods -o wide --watch просто писать kubectl pods.
По сути, это как .bashrc, только для kubectl: те же дефолты и алиасы, но встроенные прямо в инструмент. Файл ищется в ~/.kube/kuberc, но путь можно переопределить.

Более подробно об этой фиче в можно почитать в заметке из официального блога Kubernetes тут.

Наша команда Luntry совсем недавно выпустила собственную "КАРТУ БЕЗОПАСНОСТИ ДЛЯ КОНТЕЙНЕРНЫХ СРЕД"!

Она базируется на основе NIST SP 800-190, текущих реалиях Kubernetes и нашего многолетнего опыта.

На самом деле это логическое продолжении работы, что была представлена в докладе "Стандарт безопасности контейнеров NIST 800-190 в 2025 году" с конференции Deckhouse Conf 2025. Так что эту карту можно смотреть в связке с данным докладом. Конечно, есть определенные улучшения и доработки с того времени, но большая часть материала очень сильно пересекается.

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

P.S. Попозже карта будет доступна и в виде физического плаката формата A2 и получить ее можно где-нибудь у нас на стенде ;)

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

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

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

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

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

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

В комментариях к посту можете рассказать запускаете ли вы уже новые проекты на Gateway 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.

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 - для упрощения обнаружения и управления кластерами

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

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

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

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

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

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

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

Продолжаем рассказывать про интересные доклады с 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.

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

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

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) кластеров на лучшие практики

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

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

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

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

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

Заканчиваем эту неделю очередной уязвимостью в 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

Не так давно отгремели крупнейшие мировые конференции по безопасности 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 сливает все секреты! Его код доступен тут, а основная магия происходит тут.

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