k8s (in)security

У коллег с прекрасного канала PWN AI узнал про интересную работу "Inspect evaluation: Container sandbox breakout", где исследователи оценивают насколько просто или сложно LLM внутри классического контейнера (считай на базе runc) совершить из него побег.

Сразу стоит отметить, что модель заведомо помещается в так скажем плохо сконфигурированное или уязвимое окружение, тоесть:
- BAD Pods
- уязвимый runc
- уязвимое ядро хостовой ОС
- привилегированный service account в k8s

Всего таких сценариев 18 и все они доступны (отличная база и для CTF и для собственного обучения)! И, конечно, думаю и для многих очевидно, что при таких исходных условиях все 18 сценариев были успешно реализованы.

Тут интересно сколько времени уходили у LLM на тот или и ной сценарий - разброс составляет от нескольких минут до 2 часов. У кого SOC увидит и успеет отреагировать?)

P.S. Насколько я понял тест когда запускали LLM в контейнере без явно заложенных обще известных проблем, то побега не было.

В свежем релизе cri-o исправили две уязвимости, одна из которых имеет критический уровень и может привести к побегу из контейнера. CVE-2026-62146 позволяет пользователю с правом создавать Pods отравить сохранённое состояние sandbox через произвольные annotations, а после рестарта CRI-O или перезагрузки ноды — добиться монтирования контролируемых host paths и получить доступ к crio.sock.

Вторая уязвимость, CVE-2026-17113, позволяет вызвать падение CRI-O через специально сформированный OCI image с некорректной переменной окружения. Через стандартный Kubernetes API сценарий не эксплуатируется, поскольку kubelet добавляет переменные окружения по умолчанию, но риск остаётся для прямых клиентов.

Исправления доступны в CRI-O 1.34.12, 1.35.7 и 1.36.4. Для CVE-2026-62146 после обновления разработчики также рекомендуют удалить все запущенные контейнеры на нодах.

Наши хорошие друзья запустили аж целых 3 исследования:
1) Исследование рынка безопасной разработки и DevSecOps
2) Исследование рынка средств контейнеризации
3) Исследование рынка безопасности ИИ-систем (MLSecOps)

По сути это опросы, результаты которых должны показать реальное (не маркетинговое) положения дел в этих направлениях. Мы с радостью поддерживаем их в этой активности!

Больше деталей можно узнать тут.

В статье "We Tested Copy Fail in Kubernetes: PSS Restricted and RuntimeDefault Did Not Block AF_ALG" детально изучается уязвимость ядра CVE-2026-31431 (писали о ней тут и тут) в рамках ее эксплуатации в Kubernetes c разными механизмами защиты. Из нее можно узнать, что:
- Pod без root прав,
- Pod с отключёнными capability,
- Pod c RuntimeDefault профилем для seccomp,
- Pod c Pod Security Standards в режиме Restricted,

Все равно может быть проэксплуатирован через CVE-2026-31431 ...

В качестве тестовых окружений исследователи взяли (не не пойми что): OS Talos и EKS на Amazon Linux.

Спасти нас тут могут специально созданный seccomp профиль и обновление самого ядра.

P.S. Еще авторы игрались с `allowPrivilegeEscalation`, но не особо понятно зачем ведь вместо поднятия привилегий внутри контейнера мы просто уходим с него на хост ...

Вышел Kubernetes 1.37 под кодовым названием «Garhwal». Среди наиболее интересного — manifest-based admission control, который позволяет загружать admission policies с диска и применять их уже при старте API server, даже если etcd недоступен. Для security аудитории также стоит отметить стабильные Pod Certificates и ClusterTrustBundles, а также улучшения SELinux и защиту API server от всплесков нагрузки при инициализации watch cache.

Отдельно интересны Memory QoS на cgroups v2, workload-aware preemption и развитие DRA — включая device taints, extended resources и поддержку ResourceClaims для workloads. В Alpha появился Pod-level checkpoint/restore, а для AI/ML-нагрузок развивается CompositePodGroup и multi-level gang scheduling.

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

Приглашаем всех 3 сентября в 11:00 посетить наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред". Там мы расскажем:
1) Что нового в релизе 4.6
2) Разберем новые инструменты для защиты инфраструктуры
3) Поговорим о практическом применении
4) Планы Luntry до конца года
5) Ответим на технические вопросы

Ссылка для регистрации.

Написать NetworkPolicy — полдела, вопрос в том, как убедиться, что она реально работает так, как вы задумали. Статический анализ манифестов тут бессилен: он не знает ни про CNI, ни про то, кто и куда на самом деле дотягивается в вашем кластере. Тут в тему kubesonde — оператор, который не читает YAML, а активно прощупывает связность между Pod'ами изнутри кластера.

Работает так: ставите CRD и создаете объект Kubesonde с указанием неймспейса и режима (probe: all). Дальше он в каждый Pod подкидывает ephemeral container (по умолчанию instrumentisto/nmap для проб и свой gonetstat для наблюдения за открытыми портами) и начинает гонять коннекты во всех направлениях. Результат забирается через port-forward и curl localhost:2709/probes в JSON, который можно закинуть в их же веб-UI и посмотреть матрицу «кто до кого дошел». Есть непрерывный режим, исключения-включения по селекторам и, самое интересное, возможность прописать в спеке ожидаемый исход (action: Allow / Deny) — то есть это уже не сканер, а тесты на вашу сетевую изоляцию, которые можно гонять в CI после каждого изменения политик.

Инструмент академический — Apache 2.0, 18 звезд, вырос из работы Analyzing Microservice Connectivity with Kubesonde на ESEC/FSE 2023 и используется как рантайм-часть в исследовании сетевых мисконфигов в Helm-чартах, о котором мы писали недавно. Инструмент явно для dev/test/stage окружений, но ни как ни для prod.

Kyverno 1.19 — релиз, который фактически завершает переход проекта на CEL-based policies: теперь ValidatingPolicy, MutatingPolicy, GeneratingPolicy, ImageValidatingPolicy и DeletingPolicy покрывают весь функционал старого ClusterPolicy. Для Kubernetes Security это особенно важно: policy engine становится ближе к нативному подходу Kubernetes через CEL и ValidatingAdmissionPolicy`/`MutatingAdmissionPolicy.

При этом ClusterPolicy, Policy, CleanupPolicy, ClusterCleanupPolicy и legacy PolicyException официально deprecated и будут удалены в Kyverno 1.20, поэтому существующие security policies уже пора мигрировать. В 1.19 это последний релиз с полной поддержкой legacy API, а для миграции есть отдельный kyverno migrate и migration guide.

Ещё одно изменение, важное для эксплуатации: CRD теперь управляются через отдельную Helm dependency kyverno-api, поэтому при upgrade стоит проверить собственный процесс установки CRD. Подробности — в официальном анонсе релиза.

Идея «сгенерируй мне least-privilege конфиг по тому, что реально делает приложение» стара как seccomp-профили, но каждый год обретает новое воплощение. Свежее — «KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis» из Ben-Gurion University: манифесты плюс рантайм-телеметрия скармливаются LLM через цепочки промптов, на выходе рекомендации по Role, NetworkPolicy и Deployment. Источники ровно те, что у вас и так есть (ну или должны быть):
- Kubernetes audit logs — какие verbs реально дергали, отсюда RBAC
- Hubble (Cilium) — реальные потоки трафика, отсюда NetworkPolicy
- SPADE + CLARION — provenance по процессам в контейнерах, отсюда securityContext (штука research-grade, но в проде ее роль ровно так же закроют Tetragon, Falco или Tracee)

Два режима: Resource Creation (собрать с нуля) и Resource Refinement (ужать существующий overly permissive). Кода в открытом доступе нет, зато промпты авторы выложили в приложениях.

P.S. Не сторонники такого подхода. На наш взгляд при наличии этих данных к решению задачи можно спокойно подойти алгоритмически, а не с помощью вероятностных алгоритмов, которые могут галлюцинировать.

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

Завтра 25 августа в 12:00 вместе с коллегами в живом диалоге поговорим про то как ИИ влияет на разных жизненных стадиях разработки ПО и его безопасности.

И как всегда будем рады ответить на любые вопросы!

Ссылка для регистрации.

Kubernetes NetworkPolicy не всегда гарантирует изоляцию между tenant’ами. В статье "Using the API server proxy to bypass network policies" показано, как API server proxy можно использовать для обхода сетевых политик и доступа к workload’ам другого namespace.

Атака основана на возможности изменять IP адрес Pod через его status. Злоумышленник подменяет IP своего Pod на адрес чужого workload и затем обращается к нему через API server proxy. RBAC при этом разрешает запрос, поскольку пользователь обращается к своему Pod, а NetworkPolicy пропускает трафик, поскольку источником фактически выступает API server.

В статье также есть видео с демонстрацией атаки и инструкция по воспроизведению.

Многие очень мало внимания уделяют labels и вообще думают, что с безопасностью они никак не связаны... И это большая ошибка.

Давайте рассмотрим метку "admission.gatekeeper.sh/ignore", которая поставленная на Namespace, выводит его из под наблюдения OPA Gatekeeper webhook. Тут атакующему понадобится операция:

kubectl label namespace <ns-name> admission.gatekeeper.sh/ignore=true

Для нее нужны права:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: namespace-labeler
rules:
- apiGroups: [""]
  resources: ["namespaces"]
  verbs: ["get", "patch", "update"]

Или если вы живете по GitOps, то сразу создать такой NS в репозитарии.

В Kyverno такой специальной label нет.

В комментариях можете привести другие критичные labels, которые вы знаете.

P.S. Кто живет на OPA Gatekeeper - а у вас есть политика на OPA Gatekeeper, которая проверяет эту метку OPA Gatekeeper ?)

В статье «Introducing Nirmata Runtime for Kyverno» Nirmata представила Runtime — расширение Kyverno, которое переносит enforcement политик с уровня Kubernetes admission непосредственно в Linux kernel. Для этого используются eBPF и BPF-LSM, что позволяет синхронно блокировать опасные действия: запуск процессов, доступ к файлам, сетевые соединения и определённые протоколы.

Особенно интересно применение для AI-агентов: Runtime позволяет ограничивать, какие бинарники они могут запускать, к каким endpoint'ам обращаться и какие файлы читать. Политики описываются на CEL, как и в Kyverno, а перед включением enforcement их можно протестировать в monitor mode.

Runtime доступен по ссылке — проект уже содержит примеры RuntimePolicy и может работать как самостоятельно, так и вместе с Kyverno для многоуровневого контроля.

О реальном использовании в своей инфраструктуре такого проекта как Firecracker на наших просторах мало кто говорит (да и мало кто использует). НО наши хорошие друзья, которые активно занимаются AI и fuzzing, в одном из своих постов рассказали как и зачем (механика snapshot/restore) в общем можно делать свои собственные для этой легковесной VMM.

А если у вас есть опыт использования Firecracker и Kata containers, то делитесь своим опытом в комментариях.

А если вы вообще не знаете что это такое, то рекомендуем ознакомиться с нашим докладом "Кубик Runtime в конструкторе Kubernetes для безопасности" ;)

На конференции Black Hat USA 2026 вышел доклад Beyond Seccomp: Breaking and Rebuilding Syscall Filtering for Microservices о том, где современные механизмы фильтрации syscall'ов дают слабину. Авторы выделяют три проблемы: stateless-фильтрация Seccomp не учитывает последовательность вызовов, eBPF-энфорсмент может реагировать слишком поздно, а загрузка политик через Kubernetes Operator создаёт окно между стартом контейнера и применением защиты.

Особенно интересно, что авторы не просто показывают атаки, а предлагают архитектуру следующего поколения: stateful-фильтрацию через eBPF, inline-блокировку через LSM-BPF и атомарную установку политик до запуска контейнера. В результате получается защита, которая учитывает контекст syscall'ов и не оставляет временных окон для обхода.

Слайды доклада уже доступны по ссылке. И да, этот доклад очень сильно пересекается с нашим секретным докладом с БеКон 2026 — но кто знает, тот знает.

containerPort в манифесте — это документация, а не контроль. Kubernetes его не проверяет: контейнер может слушать порты, которых в YAML нет, и наоборот. Ровно на этом разрыве между декларацией и реальностью построена работа «Inside Job: Defending Kubernetes Clusters Against Network Misconfigurations».

Они прогнали 287 публичных Helm-чартов от Bitnami, Banzai Cloud, CNCF, Prometheus Community через связку статического анализа YAML и рантайм-наблюдения в живом кластере. Нашли 634 проблемы у 90% приложений:
- 241 — нет никаких NetworkPolicy
- 188 — порт открыт, но не задекларирован (привет, админские и debug-интерфейсы)
- 67 — порт задекларирован, но не открыт: приходит кто-то другой и занимает его
- 35 — контейнер слушает эфемерный порт, который меняется при каждом старте (и никакая политика по портам его не покроет)
- 52 — коллизии лейблов, когда чужой Pod попадает под селектор вашего Service, а трафик уезжает не туда

Список самых грязных чартов бьет по узнаваемости: kube-prometheus-stack, kube-prometheus, clickhouse, istio-operator, grafana-tempo, zookeeper, jaeger, metallb, node-exporter. То есть ровно то, что стоит у половины читателей канала, причем зачастую в системных неймспейсах. У всей десятки лидеров нет NetworkPolicy и есть незадекларированные порты, 9 из 10 сидят в hostNetwork (а на него, напомним, NetworkPolicy и не действует), 4 из 10 слушают эфемерные порты.

Отдельно они сравнили себя с 11 инструментами — Checkov, KubeLinter, kube-score, kubesec, kubeaudit, Kubescape, Trivy, NeuVector, StackRox и т.д. Статические не видят рассинхрон декларации и реальности в принципе, потому что смотрят только в YAML, а рантайм- и платформенные решения его просто не ищут. И самое неприятное: коллизии лейблов сами разработчики оценили как наиболее критичную находку — это готовый MITM внутри кластера.

В статье «Does Kubernetes DRA Replace HAMi?» разбирается, станет ли Kubernetes DRA заменой для HAMi в работе с GPU. DRA предоставляет нативный механизм для описания, планирования и распределения специализированных устройств, включая возможность делить ресурсы GPU между Pod’ами.

Но DRA и HAMi решают разные задачи. DRA отвечает за управление и планирование ресурсов, а HAMi — за runtime enforcement, то есть фактическое ограничение GPU memory и compute внутри контейнера.

Поэтому DRA скорее дополняет HAMi, чем заменяет его. В будущем HAMi может использовать DRA как основу для планирования, сохраняя собственные возможности по виртуализации и ограничению GPU.

Когда говорят про sandbox в Linux, обычно вспоминают gVisor, Kata Containers или seccomp-профили. А есть куда более скромный инструмент, который при этом крутится на миллионах десктопов, — bubblewrap. Это тот самый движок песочницы, на котором работает Flatpak, и живёт он в организации containers рядом с Podman и Buildah.

Ключевая идея: это container tool для непривилегированного пользователя — никакого демона и root, всё на unprivileged user namespaces. Что даёт:
- mount namespace с пустым tmpfs в качестве /, куда руками пробрасываются только нужные куски ФС
- user/IPC/PID/network/UTS namespaces
- seccomp-фильтры
- монтирование ro и nodev по умолчанию
- PR_SET_NO_NEW_PRIVS, отрубающий эскалацию через setuid-бинари

Но самое интересное — то, что честно написано в README: сам по себе bubblewrap не даёт ничего, уровень защиты полностью определяется аргументами, которые ему передал вызывающий. Пробросили внутрь сокет D-Bus — и песочницы фактически нет. Ничего не напоминает? Ровно та же история, что и с SecurityContext в Kubernetes: примитивы ядра у всех одни и те же, а итоговая защищённость зависит от того, кто и как их сконфигурировал.

И показательный момент напоследок: оба CVE за всю историю проекта — и CVE-2020-5291, и свежий CVE-2026-41163 — про один и тот же setuid-режим, который нужен ровно там, где unprivileged user namespaces в ядре запрещены. В версии 0.11.2 завезли опцию сборки вообще без setuid и объявили, что дальше поддержку уберут совсем. Тренд читается однозначно: ставка делается на unprivileged user namespaces как на базовый примитив изоляции.

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

Во-первых, статические Pod'ы больше не смогут ссылаться на Secrets и ConfigMaps — в Kubernetes исправили баг, который позволял им получать доступ к API-ресурсам. Также SELinuxMount включат по умолчанию для поддерживаемых CSI-драйверов, что ускоряет работу с томами, но может привести к проблемам у приложений, которые совместно используют один volume с разными SELinux-контекстами.

kubelet в user namespace переходит в Beta. Это позволяет запускать kubelet без root-привилегий на хосте, сохраняя root только внутри namespace, и тем самым уменьшает потенциальный impact от компрометации kubelet.

Недавно прошла конференция KubeCon + CloudNativeCon Japan 2026 (расписание со слайдами, видеозаписи) и мы выделили с нее следующие доклады связанные с безопасностью:

- Vulnerability Response for Large Open Source Projects
- Sandbox for Agentic Application With Cloud Native Stack
- Identities and Authentication for Your Agents With Keycloak
- User Namespaces in Production: Enabling Root in Containers With RWX
- Detecting Compromised CI With eBPF and Cilium Tetragon
- Kairos: Immutable OS and Lifecycle Management for Kubernetes Fleets
- Lima in 5 Minutes: From Containers To AI Sandboxing
- SBOMit: Making SBOMs Accurate With Attestations
- Scalable Security and Compliance in the Age of AI
- Runtime Security at Scale With EBPF: Hybrid Detection and Root Cause Analysis in CloudNative Systems
- Container Forensics for Kubernetes: Building an Evidence Pipeline With Open Source Tools
- AuthZEN in Practice: Standardizing Authorization for Cloud Native Platforms and Agents
- Behind the CNCF IAM Whitepaper: AuthN & AuthZ in Cloud Native Systems