k8s (in)security

В статье «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

Очередная LPE уязвимость в Linux — SCTPhantom (CVE-2026-64564), связанная с use-after-free в реализации SCTP. Проблема появилась ещё в ядрах 2.6.25 и связана с некорректной обработкой ASCONF-сообщений, которая приводит к повторному использованию уже освобождённого sctp_transport. Самое интересное здесь — возможность превратить уязвимость в container escape. Исследователям удалось построить цепочку эксплуатации, которая позволяет процессу из контейнера повысить привилегии через ядро и выйти за пределы контейнерной изоляции, получив контроль над хостом. Для Kubernetes это особенно неприятный сценарий: контейнерная изоляция в конечном итоге опирается на ядро хоста, и kernel-level UAF способен превратить компрометацию контейнера в компрометацию всей ноды. Исправление уже отправлено upstream.

k8s (in)security pinned a video

Работа с container registry у многих до сих пор сводится к docker pull / docker push, а значит к запущенному демону, docker.sock в раннере и лишним привилегиям там, где они совсем не нужны. regclient — это Go-библиотека и три CLI для работы с OCI-совместимыми реестрами без container runtime и без привилегированного доступа к хосту: - regctl — инспекция, копирование и ретегирование с сохранением digest, работа с OCI Artifacts, referrers и мультиплатформенными индексами, плюс regctl image mod (аннотации, timestamps, смена базового образа и алгоритма digest) - regsync — зеркалирование по YAML-конфигу: по расписанию, разово или только отчётом об устаревших образах, с поддержкой OCI Layout для переноса через air-gap - regbot — скриптование политик на Lua: обход репозиториев, удаление лишних тегов и манифестов, с оглядкой на rate limits Самое интересное здесь — поддержка referrers и digest tags: именно в них живут подписи cosign и аттестации с SBOM. Если тянуть образы во внутренний реестр инструментом, который про них не знает, то образ доедет, а доказательства его происхождения — нет, и вся выстроенная supply chain security тихо превращается в тыкву. И да, regctl image mod с regbot одинаково удобны как для наведения порядка в реестре, так и для того, чтобы незаметно в нём что-то поправить — права на запись в registry стоит раздавать так же скупо, как и в кластер ;)

🔝 Вспоминаем, как это было на БеКон 2026! 🔥 Конференция осталась позади, но самый сок теперь доступен онлайн. Все доклады, драйв, инсайты и презентации от топ-экспертов рынка (Luntry, Т-Банк, Альфа-Банк, Ozon, АСТРА и др.) уже ждут вас на сайте. Пересматривайте лучшие моменты, скачивайте слайды и внедряйте лучшие практики в своих проектах. 👇 Забирайте материалы прямо сейчас: 📺 Записи докладов тут 📂 Презентации тут Ставьте ❤️ и делитесь постом с коллегами, которым это будет полезно! 🚀

User Namespaces — одна из самых значимых функций безопасности Kubernetes последних лет, но её работа гораздо сложнее, чем может показаться на первый взгляд. В статье User Namespaces in Kubernetes, Part III: The Implementation подробно разбирается, как kubelet, CRI и OCI Runtime совместно создают отдельные user namespace для каждого Pod и управляют UID/GID. Автор также объясняет, как Kubernetes резервирует диапазоны идентификаторов, хранит их состояние и предотвращает конфликты между Pod'ами. Отдельное внимание уделено интеграции с idmapped mounts, благодаря которой User Namespaces работают с томами без изменения владельцев файлов. Это отличный материал для тех, кто хочет разобраться не только в использовании User Namespaces, но и понять, какие изменения потребовались внутри Kubernetes для реализации этой функции и почему она так долго находилась в разработке.

В известном решении по безопасности Tetragon закрыли «Unauthenticated Tetragon gRPC admin API accessible from hostNetwork pods» - CVE-2026-65960 (CVSS 8.8). Суть простая: агент поднимает свой административный gRPC API по TCP на localhost:54321 и без какой-либо аутентификации. Таким образом любой злоумышленник на Node или Pod с hostNetwork: true живёт в сетевом namespace узла — значит этот localhost и его тоже. Что из такого пода может атакующий: - добавлять, удалять и перенастраивать TracingPolicy - менять debug-настройки - в целом крутить поведение агента вплоть до container escape и повышения привилегий Починили в v1.7.0 - уязвимы абсолютно все версии до этой! Отдельно обратите внимание на механику: атакующему здесь не нужно ничего эксплуатировать в первую очередь — ему нужно выключить наблюдение. Снёс TracingPolicy — и дальше работает вслепую для SOC, который как раз на Tetragon и завязан. Средства защиты сами являются частью attack surface и требуют харденинга не меньше, чем прикладные нагрузки, а hostNetwork: true в очередной раз стоит читать как «почти привилегированный под» =)

В Kubernetes постепенно появляются z-pages — специальные диагностические endpoint'ы (statusz, flagz, configz), которые помогают понять реальное состояние компонентов кластера. На практике именно configz наиболее полезен для аудита безопасности, так как показывает итоговую конфигурацию с учётом файлов конфигурации, а не только параметров командной строки. Автор статьи Show us Zee Pages, Rory McCune показывает, почему полагаться только на flagz опасно. Если компонент использует конфигурационные файлы, информация может быть неполной или даже вводить в заблуждение. При этом доступ к configz неодинаков для разных компонентов Kubernetes, а для некоторых из них требуются дополнительные права и сетевой доступ. Чтобы упростить анализ, автор разработал утилиту zeedumper, которая собирает данные из statusz, flagz и configz, а также пытается восстановить отсутствующие значения по умолчанию. Это может заметно облегчить аудит и проверку конфигурации Kubernetes-кластеров.

Дефолты — это не константа, а свойство конкретной версии. Меняются они между минорными релизами, а иногда и между патчами, так что любой ваш снимок «как оно настроено из коробки» имеет срок годности. Показательный случай — CVE-2025-46599 в K3s. В ветке 1.32 конфигурацию kubelet перевели с устаревших CLI-флагов на структуру v1beta1.KubeletConfiguration с генерацией YAML drop-in. А у поля ReadOnlyPort в апстримной go-структуре стоит omitempty — и значение 0 просто выпало при маршалинге. kubelet подставил свой дефолт и поднял 10255: неаутентифицированный доступ к /pods со со спецификациями Pod’ов, включая потенциально чувствительные значения в env, аргументах запуска и других полях; в отдельных конфигурациях это могло приводить к раскрытию токенов и credentials. Разбор — в issue #12164, починили только в 1.32.4-rc1+k3s1, то есть проблема присутствовала в нескольких последовательных релизах ветки 1.32. А теперь самое интересное. Всё это время CIS self-assessment guide в пункте 4.2.4 писал ровно обратное: «By default, K3s sets the --read-only-port to 0». И сама проверка сформулирована так: Expected Result: '--read-only-port' is equal to '0' OR '--read-only-port' is not present. После рефакторинга флага в командной строке kubelet не стало — то есть автоматический аудит по этому пункту честно рапортовал PASS, пока порт слушал. Один и тот же коммит и открыл дыру, и ослепил проверку. Вывод простой и невесёлый: все всегда стоит перепроверять и подвергать сомнению =)

ControlPlane опубликовала Kyverno End User Threat Model — открытую модель угроз для пользователей Kyverno. Она помогает понять, какие активы защищает Kyverno, какие существуют доверительные границы, кто может быть атакующим и через какие сценарии возможна компрометация. Модель охватывает такие компоненты, как Admission Controller, Background Controller, Policy Reports, вебхуки, Kubernetes API и взаимодействие с внешними системами. Для каждого сценария описаны возможные последствия и существующие механизмы защиты. Это полезный материал не только для пользователей Kyverno, но и для всех, кто внедряет policy-as-code в Kubernetes. Вместо разрозненных рекомендаций можно увидеть систему целиком и понять, какие риски действительно стоит учитывать при эксплуатации платформы.

Usernetes разворачивает Kubernetes без root на хосте (писали о нем еще в 2020) — чтобы побег из контейнера никуда не вёл. На днях проект перешёл с Gen2 на Gen3. Gen2 умел ровно один режим: Kubernetes-in-Docker поверх Rootless Docker/Podman/nerdctl — как rootless kind, только с поддержкой нескольких хостов. Gen3 — надмножество: этот режим остался дефолтным, а сверху приехал Kubernetes-in-Kubernetes, где внутренний кластер живёт во внешнем в виде подов с hostUsers: false (KEP-127, UserNamespaces GA в 1.36). Что тут важно для c точки зрения ИБ: - node-поды не используют privileged: true. Вместо него — все namespaced capabilities, procMount: Unmasked и unconfined seccomp/AppArmor, а изоляцию держит user namespace. Тот же приём применён к kube-proxy внутреннего кластера: privileged выкинут в пользу NET_ADMIN и NET_RAW - при этом namespace обязан разрешать профиль privileged в Pod Security admission — снаружи картина максимально пугающая, хотя это ровно тот случай, ради которого userns и создавали - kubelet выдаёт каждому userns-поду свой диапазон в 65536 UID/GID, причём /etc/subuid хостов не участвует вообще — тенанты не пересекаются по UID даже на одной ноде Цена вопроса: containerd >= 2.1 с отдельным runtime handler и cgroup_writable = true (включать его на дефолтном runc авторы прямо не советуют — заденет все непривилегированные поды), ядро >= 6.3 ради idmapped mounts для tmpfs, и сам режим помечен как экспериментальный. Зато отлично видно, до чего доросли user namespaces: целый кластер с kubelet, containerd и etcd уезжает внутрь пода — и без privileged =)

Istio представил новый API TrafficExtension, который объединяет настройку расширений Envoy на базе WebAssembly (Wasm) и Lua в едином интерфейсе. Раньше для Wasm использовался WasmPlugin, а Lua-скрипты приходилось подключать через низкоуровневый EnvoyFilter, который был сложен и подвержен ошибкам. Новый API работает с сайдкарами, ingress/egress-шлюзами и waypoint-прокси, а также поддерживает как классический sidecar-режим, так и Ambient Mode. Это позволяет использовать единый способ расширения трафика независимо от архитектуры сервиса и упрощает миграцию между режимами работы Istio. По сути, Istio делает расширение data plane гораздо более безопасным и удобным. Вместо ручной работы с EnvoyFilter пользователи получают декларативный API с поддержкой сразу двух популярных механизмов кастомизации.

Прод встал колом по CPU, а перезапускать поды нельзя — знакомая история. Обычно дальше начинается танец с ephemeral containers и пересборкой образа с профайлером внутри. Google выложил app-toolbox — кастомную сборку штатного COS Toolbox образа для хостов на Container-Optimized OS (ноды GKE, обычные GCE VM), которая снимает профили с живых контейнеров, ничего не перезапуская: - Java — JFR через jattach, zero-copy, работает даже с read-only ФС контейнера - Python — py-spy с --nonblocking и --idle - Golang — on-CPU профилирование через bpftrace - Node.js — off-CPU профилирование на eBPF - системная диагностика: biolatency, tcpretrans, offcputime в CO-RE варианте, то есть без kernel headers Всё это заворачивается интерактивным скриптом app-collector, результат складывается в .tar.xz с SHA-256. Идеи и бинари можно переиспользовать для собственной реализации в рамках своего окружения ;)

В CRI-O обнаружили новую уязвимость CVE-2026-15809, которая оказалась обходом исправления четырехлетней давности для CVE-2022-4318. Из-за ошибки в реализации защита никогда не работала так, как предполагалось: код искал строку `\n` вместо реального символа перевода строки. Злоумышленник, способный задать переменные окружения контейнера, может внедрить перевод строки в переменную HOME и тем самым добавить произвольные записи в /etc/passwd. Это открывает путь к повышению привилегий внутри контейнера и показывает, насколько опасными могут быть ошибки в механизмах, отвечающих за создание контейнеров. Особенно примечательно, что проблема существовала с декабря 2022 года, несмотря на наличие официального исправления.

Недавно мы задавались вопросом, а какие вообще сейчас есть способы взять и забрать image с Node в Kubernetes. В результате появилась вот такая нехитрая сравнительная таблица.

3 года назад мы уже писали про бесплатную open-source платформу, которая помогает готовится к экзаменам CKA, CKAD и CKS или просто освоить Kubernetes. И есть отличная новость - проект живой и развивается. На пример, его команда недавно добавила курс по Istio и лабы к нему! Это будет максимально полезно если готовитесь (или просто смотрите в сторону) к Istio Certified Associate (ICA).

В официальном блоге Kubernetes есть статья «The Invisible Rewrite of the Kubernetes Image Promoter», и это отличный повод поговорить про безопасность цепочки поставок с непривычной стороны. Все любят обсуждать её на уровне cosign и SLSA, но мало кто задумывается, через какой именно код физически проходит каждый официальный образ k8s. А проходит он через kpromo — image promoter, который тащит образы из staging в registry.k8s.io, подписывает их через cosign, раскатывает подписи по 20+ региональным зеркалам и генерит SLSA -provenance. Если он падает — не выходит ни один релиз Kubernetes. То есть это буквально корень доверия для всего дистрибутива образов. И вот эту критичную штуку по-тихому переписали. За плечами у promo-tools 7 лет наслоений: монолитная логика промоушена, дубли, боль с тестами, регулярные rate limit-падения и 30+ минут на прод-джобу. Как итог: −20% кода, заметное ускорение, и всё это с нулевым даунтаймом — никто ничего не заметил =) Отдельно приятно, что тут же живут SBOM и vulnerability scanning, то есть весь supply-chain обвес.