k8s (in)security
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Show more📈 Analytical overview of Telegram channel k8s (in)security
Channel k8s (in)security (@k8security) in the Russian language segment is an active participant. Currently, the community unites 13 192 subscribers, ranking 9 287 in the Technologies & Applications category and 48 734 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 13 192 subscribers.
According to the latest data from 05 October, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 129 over the last 30 days and by 4 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 28.61%. Within the first 24 hours after publication, content typically collects 11.96% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 773 views. Within the first day, a publication typically gains 1 577 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 18.
- Thematic interests: Content is focused on key topics such as kubernetes, контейнер, luntry, кластер, kyverno.
📝 Description and content policy
The author describes the resource as a platform for expressing subjective opinions:
“Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений.
Ведет команда www.luntry.ru
#ZST99
Вопросы, идеи, предложения => @Qu3b3c
https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission”
Thanks to the high frequency of updates (latest data received on 06 October, 2026), the channel maintains relevance and a high level of publication reach. Analytics show that the audience actively interacts with content, making it an important point of influence in the Technologies & Applications category.
Palo Alto Networks показали интересный сценарий атаки на SPIFFE/SPIRE в Kubernetes. Если атакующий получает root на ноде, он может подменить cgroup метаданные процесса и заставить SPIRE Agent выдать ему SVID другого workload.
В результате злоумышленник получает возможность использовать криптографическую идентичность скомпрометированного workload и обращаться к сервисам, доверяющим этой identity. При этом сама криптография SPIFFE не ломается — проблема в том, что после компрометации ноды рушится доверие к данным, на которых основана workload attestation.
Для проверки таких сценариев Palo Alto Networks выпустили открытый инструмент Spooffe, который автоматизирует тестирование подмены cgroup и получения чужих SVID. Хорошее напоминание о том, что SPIFFE/SPIRE не изолирует workload от полностью скомпрометированной ноды и root доступ нужно учитывать в threat model.AI Bill of Materials в Kubernetes.
В AI-проектах уже недостаточно знать только версии контейнеров и пакетов. Важно понимать, какие AI-модели, фреймворки и компоненты реально используются в кластере, где они запущены и от чего зависят. Что и как он идентифицирует можно почитать тут.
Команда Google Cloud представила k8s-aibom — инструмент с открытым исходным кодом, который помогает автоматически собирать AIBOM.
Что инструмент дает:
- инвентаризацию AI-компонентов в кластере;
- понимание, какие модели и ML-фреймворки используются;
- повышение прозрачности AI-нагрузок;
- помощь в анализе рисков, уязвимостей и соответствия требованиям безопасности;
- более удобный контроль AI-софта в production-средах.
Со временем окружение быстро усложняется, а ручной учет компонентов становится практически невозможным. По сути, k8s-aibom — это попытка сделать для AI-компонентов то же, что SBOM (только в формате OWASP CycloneDX 1.6 Machine Learning Bill of Materials (ML-BOM)) делает для обычного программного обеспечения: дать структурированное представление о составе системы, чтобы защитить цепочку поставки (supply chain), борьба с shadow AI.AI-агентов вместе с декларацией того, какие доступы ему нужны.
Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime.
Но формат не ограничен агентами: им можно описывать потребности обычных сервисов!
По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру.
Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория.
P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года.Docker выпустил свой официальный набор skills для работы со своими решениями:
- Dockerfile & Build
- Docker Compose
- Docker Sandboxes
- Docker Agent
- Cross-Product
В общем если вы активно работаета с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться.runtime security агент на eBPF под названием Bombini, который целиком написанный на Rust с библиотекой Aya.
Он построен на BPF LSM хуках и состоит из модульных детекторов, которые отслеживают процессы, файловые и сетевые операции, а также взаимодействие с eBPF-подсистемой ядра.
Самое интересное здесь — rule engine, который целиком работает внутри eBPF в отличие от Falco, где правила вычисляются в user mode части агента. Правила пишутся в YAML с булевыми предикатами (AND/OR/NOT, in, CIDR для IPv4/IPv6, списки и макросы). Каждое правило компилируется как программа: парсер строит AS`T, оптимизационные проходы его упрощают, а на выходе получается байткод в обратной польской записи. Байткод загружается в `eBPF-мапы и исполняется прямо в ядре собственным RPN-интерпретатором. Поэтому фильтрация происходит до отправки событий в userspace, и накладные расходы минимальны. Для правил есть sandbox-режим в вариантах allow-list и deny-list, в отличие от Tetragon, где реализован только deny-list способ.
Отдельно стоит отметить детектор SysEnumMon, аналогов нет ни в Falco, ни в Tetragon. Обычно в eBPF-агентах одно срабатывание хука даёт одно событие. SysEnumMon работает иначе: он собирает наблюдения с нескольких хуков (запуск бинарей и открытие файлов), коррелирует их внутри дерева процессов в скользящем временном окне и принимает решение прямо в eBPF. Так он ловит сканеры вроде LinPEAS и LinEnum, хотя каждое их действие по отдельности (id, uname, чтение /etc/passwd) выглядит легитимно.
Подробнее о проекте можно узнать тут и тут.Kubernetes, напоминает нам о том что надо защищать и патчить не только компоненты control и data plane, но и kubectl.
CVE-2026-19444: kubectl cp path traversal on Windows allows arbitrary file writes
CVSS Rating: CVSS:3.1/AV:A/AC:L/PR:H/UI:R/S:C/C:L/I:H/A:N
Medium (6.5)
Если капнуть в историю, то это далеко не первая подобная бага в kubectl:
1) CVE-2018-1002100 — Первая оригинальная уязвимость kubectl cp
2) CVE-2019-1002101 — Атака через символические ссылки (Symlink Attack) в kubectl cp
3) CVE-2019-11246 — уязвимость обхода каталога (directory traversal) в команде kubectl cp
4) CVE-2019-11249 — закрывает обход предыдущих патчей для kubectl cp
Особенность новой уязвимости в том что она только под Windows. Проблема кроется в разнице обработки путей (например, разделителей путей \ против /, использования дисков C: или специфических для Windows символов), из-за чего общие кроссплатформенные проверки kubectl оказались неэффективны на Windows-системах, позволяя осуществлять несанкционированную запись произвольных файлов (arbitrary file write).GKE можно замораживать (checkpoint) состояния Pod в виде snapshot и затем запускать их с этого же момента (restore). Более подробно можно узнать об этом из документации "Save and restore Agent Sandbox environments with Pod snapshots".
И если вам кажется, что это какая-то магия и доступна только избранным пользователям GKE Sandbox, то вы ошибаетесь - такое можете сделать и вы сегодня у себя дома. Так как это все базируется на возможностях рантайма gVisor (1,2)!
Да, это еще не реализация в рамках runc/crun и KEP-5823 (Pod-level Checkpoint/Restore) на базе CRIU, но тоже вариант ;)kube-controller-manager, тоесть придется обновлять master nodes.
CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:N
Medium (5.9)
Пользователь с правами на изменение объектов StatefulSet и ControllerRevision в своём namespace потенциально может добиться создания Pod в другом namespace — с заданными им метаданными и конфигурацией.
Для эксплуатации нужны соответствующие права, а созданный Pod обычно удаляется сборщиком мусора. Чтобы он сохранился, атакующему потребуется корректно указать OwnerReference, включая UID существующего StatefulSet в целевом namespace.User Namespaces мы писали очень много (1,2,3,4,..), но и в этом материалы вы точно найдете что-то новое и полезное ;)
P.S. Всегда будет полезно посмотреть доклад "Linux user namespace в чертогах Kubernetes" с БеКон 2024namespace (не обязательно default - тут он только для примера) в любой другой namespace без простоя.
Главная идея статьи сохранение старого DNS-адреса как точки совместимости. В старом namespace можно временно оставить Service типа ExternalName, который перенаправляет запросы на сервис в новом namespace. Поэтому такой сценарий применим, например, при переносе:
- из payment в payments;
- из общего namespace в namespace команды;
- из временного namespace в production namespace;
- между namespace разных окружений внутри одного кластера.
При это внутренний и внешний трафик нужно рассматривать отдельно: перенос Service сам по себе не решает проблему Ingress. Как и по каким шагам все это сделать, какие есть подводные камни и исключения описано в данной статье.Kubernetes появилась заметка "Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and EmptyDir Permissions". Она описывает новые возможности по безопасности хранилищ (Storage):
1) Права доступа на emptyDir - на пример 01777 через emptyDir mode
2) bind mount опции - такие как noexec, nodev, nosuid через bindMountOptions
Обе фичи находятся в Alpha статусе и называются VolumeBindMountOptions и EmptyDirVolumeMode.
Очень здорово, что разработчики с каждым релизом подтягивают тот или иной аспект безопасности k8s.AI-агенты, AI сгенерированный код. Мы также уже неоднакратно писали на эту тематику. На пример, про проект Docker Sandboxes - тут, тут и тут.
Но для тех кто не знает или не помнит, напомним что это решение для macOS и Windows представляет из себя MicroVM и базируется на платформенных фреймворках виртуализации: Apple Virtualization.framework на macOS и Hyper-V на Windows.
Должно быть надежно?!
CVE-2026-79994 и CVE-2026-77179 ломают эту изоляцию ... Побег из VM на host из-за очередных проблем с symlink....
P.S. В процессе подготовки удалось словить забавное от нейронки Google Gemini, которая считает что в изолированных песочницах на macOS можно запускать только доверенные приложения )))))) наверное она что-то знает еще)))))UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит:
1) server room
2) the rack
=)
Всем хороших выходных!
P.S. Результаты конкурсов объявим в 18:00 по Мск.NeuVector — CVE-2026-78424. Проблема находится в механизме packet capture и позволяет через специально сформированный фильтр добиться OS Command Injection в привилегированном enforcer контейнере.
Для эксплуатации достаточно низких привилегий — атакующему требуется доступ с правом записи в namespaced Runtime Policies. В результате выполнение команд внутри контейнера может привести к полной компрометации worker ноды Kubernetes, а самой уязвимости присвоен CVSS 9.4.
Мы сообщили об уязвимости разработчикам NeuVector 7 августа, после чего она была исправлена в версиях 5.6.2, 5.5.4 и 5.4.11.SIG Security Kubernetes в 2025 году. Но на самом деле корректнее считать 2023 год и статью ребят из Google Cloud под названием "The Modernization Imperative: Shifting left is for suckers. Shift down instead"!
Автор статьи критикует чрезмерное «shift left» — перенос на разработчиков всё большего числа задач: тестирования, безопасности, эксплуатации, релизов и т. п. Хотя раннее подключение QA и security полезно, но на практике это нередко превращает инженеров в перегруженных «универсалов».
Вместо этого он предлагает «shift down» подход : передавать сложность вниз, на управляемые платформы и абстракции.30 сентября в Санкт-Петербурге пройдет легендарная конференция по информационной безопасности - ZeroNights!
На сайте доступна программа, а наша команда Luntry будет рада видеть вас на своей зоне и поболтать на тему безопасности контейнеров и Kubernetes! И мы рады запустить еще один конкурс с проходной на конференцию.
Конкурс: "Самая опасная уязвимость в Kubernetes"
Предыстория: На мой взгляд на текущий момент самой критичной уязвимостью найденной в Kubernetes является CVE-2018-1002105 в kube-apiserver, которая позволяла по итогу обход механизма авторизации!
Задание: Придумайте, какая уязвимость в Kubernetes могла бы по критичности быть на том же уровне или еще выше ;)
Критерий оценки:
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентябряGateway API. Помимо перехода на Gateway API v1.6, появились ExternalAuth для проверки запросов через внешний authorization service, а также TCPRoute и UDPRoute для управления L4-трафиком через тот же API. Это позволяет использовать единый Gateway для HTTP, TCP и UDP сервисов вместо комбинации Gateway API и отдельных LoadBalancer/NodePort.
Из сетевых изменений особенно интересно появление beta-поддержки IPv6 в AWS ENI IPAM, благодаря чему pod'ы в EKS могут получать маршрутизируемые IPv6 адреса из VPC. Также появился автоматический выбор netkit или veth в зависимости от версии kernel и возможность подключать собственные eBPF datapath plugins без форка Cilium.
Отдельно стоит обратить внимание на per-pod отключение source IP verification. Теперь его можно разрешить только для конкретного namespace и workload, что позволяет сохранить anti-spoofing в остальном кластере.Kyverno, где была закрыта одна серьезная уязвимость. И так получилось, что автор этой находки наш читатель и автор еще многих интересных находок в cloud native проектах: Vault Secrets Operator, Capsule, Strimzi operator, Grafana operator, Fluent Operator, VictoriaMetrics Operator и еще ряда других, которые находятся в процессе исправления. Если вам интересна данная тематика, то можно следить за ними в блоге автора и его канале. Ну и вы можете заметить, что без помощи LLM тут не обходится =)