k8s (in)security
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
نمایش بیشتر📈 تحلیل کانال تلگرام k8s (in)security
کانال k8s (in)security (@k8security) در بخش زبانی روسی بازیگری فعال است. در حال حاضر جامعه شامل 13 192 مشترک است و جایگاه 9 287 را در دسته فناوری و برنامهها و رتبه 48 734 را در منطقه روسيا دارد.
📊 شاخصهای مخاطب و پویایی
از زمان ایجاد در невідомо، پروژه رشد سریعی داشته و 13 192 مشترک جذب کرده است.
بر اساس آخرین دادهها در تاریخ 05 اکتبر, 2026، کانال فعالیت پایداری دارد. در ۳۰ روز گذشته تغییر اعضا برابر 129 و در ۲۴ ساعت گذشته برابر 4 بوده و همچنان دسترسی گستردهای حفظ شده است.
- وضعیت تأیید: تأیید نشده
- نرخ تعامل (ER): میانگین تعامل مخاطب 28.61% است و در ۲۴ ساعت نخست پس از انتشار، محتوا معمولاً 11.96% واکنش نسبت به کل مشترکان کسب میکند.
- دسترسی پستها: هر پست به طور میانگین 3 773 بازدید دریافت میکند. در اولین روز معمولاً 1 577 بازدید جمعآوری میشود.
- واکنشها و تعامل: مخاطبان بهطور فعال حمایت میکنند؛ میانگین واکنش به هر پست 18 است.
- علایق موضوعی: محتوا بر موضوعات کلیدی مانند kubernetes, контейнер, luntry, кластер, kyverno تمرکز دارد.
📝 توضیح و سیاست محتوایی
نویسنده این فضا را محل بیان دیدگاههای شخصی توصیف میکند:
“Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений.
Ведет команда www.luntry.ru
#ZST99
Вопросы, идеи, предложения => @Qu3b3c
https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission”
به لطف بهروزرسانیهای پرتکرار (آخرین داده در تاریخ 06 اکتبر, 2026)، کانال همواره بهروز و دارای دسترسی بالاست. تحلیلها نشان میدهد مخاطبان بهطور فعال با محتوا تعامل دارند و آن را به نقطه اثرگذاری مهم در دسته فناوری و برنامهها تبدیل کردهاند.
در حال بارگیری داده...
| تاریخ | رشد مشترکین | اشارات | کانالها | |
| 06 اکتبر | +5 | |||
| 05 اکتبر | +6 | |||
| 04 اکتبر | +3 | |||
| 03 اکتبر | +5 | |||
| 02 اکتبر | +6 | |||
| 01 اکتبر | +8 |
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.| 2 | k8s-aibom - это оператор для сбора 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. | 2 030 |
| 3 | Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, какие доступы ему нужны.
Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime.
Но формат не ограничен агентами: им можно описывать потребности обычных сервисов!
По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру.
Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория.
P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года. | 2 598 |
| 4 | Docker выпустил свой официальный набор skills для работы со своими решениями:
- Dockerfile & Build
- Docker Compose
- Docker Sandboxes
- Docker Agent
- Cross-Product
В общем если вы активно работаета с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться. | 3 356 |
| 5 | Сегодняшний наш герой это 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) выглядит легитимно.
Подробнее о проекте можно узнать тут и тут. | 3 104 |
| 6 | Сконцентрировавшись на серверной части инфраструктуры, мы порой непростительно забываем про клиентскую историю. Так вот очередная уязвимость в 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). | 2 584 |
| 7 | Начнем неделю со статьи "Scale your AI workloads faster and more efficiently with GKE Pod snapshots", которая рассказывает как в 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, но тоже вариант ;) | 2 524 |
| 8 | В Kubernetes была закрыта новая уязвимость.
CVE-2026-2270: StatefulSet and ControllerRevision write permissions allow cross-namespace pod creation
Уязвимость в 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. | 3 622 |
| 9 | Цикл статей "User Namespaces in Kubernetes":
1) Part I: All You Need to Know
2) Part II: Mappings and File Ownership
3) Part III: The Implementation
О User Namespaces мы писали очень много (1,2,3,4,..), но и в этом материалы вы точно найдете что-то новое и полезное ;)
P.S. Всегда будет полезно посмотреть доклад "Linux user namespace в чертогах Kubernetes" с БеКон 2024 | 3 400 |
| 10 | Из статьи "Migrating a critical Kubernetes deployment from the default namespace without any downtime" можно узнать как мигрировать микросервисы из одного namespace (не обязательно default - тут он только для примера) в любой другой namespace без простоя.
Главная идея статьи сохранение старого DNS-адреса как точки совместимости. В старом namespace можно временно оставить Service типа ExternalName, который перенаправляет запросы на сервис в новом namespace. Поэтому такой сценарий применим, например, при переносе:
- из payment в payments;
- из общего namespace в namespace команды;
- из временного namespace в production namespace;
- между namespace разных окружений внутри одного кластера.
При это внутренний и внешний трафик нужно рассматривать отдельно: перенос Service сам по себе не решает проблему Ingress. Как и по каким шагам все это сделать, какие есть подводные камни и исключения описано в данной статье. | 3 282 |
| 11 | В официальном блоге 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. | 3 074 |
| 12 | Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать 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 можно запускать только доверенные приложения )))))) наверное она что-то знает еще))))) | 3 022 |
| 13 | Итоги конкурсов!
Конкурс: "Самый желанный доклад".
Победитель @Nuclearm
С докладом про «как мы выпилили k8s и стали спать по ночам: история одного отказоустойчивого монолита». хочу услышать, как команда решилась и что потеряла.
Конкурс: "Самая опасная уязвимость в Kubernetes"
Победитель @pharma_unsafe
С багой в драйвере
Поздравляем победителей!
Победителям отдельно напишем в ЛС и расскажем как получить проходки. | 3 727 |
| 14 | Если UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит:
1) server room
2) the rack
=)
Всем хороших выходных!
P.S. Результаты конкурсов объявим в 18:00 по Мск. | 4 002 |
| 15 | Завтра последний день, чтобы поучаствовать в конкурсах и выиграть проходку на:
1) DevOops 2026 - участвовать!
2) ZeroNights 2026 - учувствовать!
еще есть время ;) | 3 871 |
| 16 | Наша команда R&D обнаружила критическую уязвимость в 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. | 7 117 |
| 17 | Я долгое время считал, что подход/термин “Shift Down Security” появился в материале SIG Security Kubernetes в 2025 году. Но на самом деле корректнее считать 2023 год и статью ребят из Google Cloud под названием "The Modernization Imperative: Shifting left is for suckers. Shift down instead"!
Автор статьи критикует чрезмерное «shift left» — перенос на разработчиков всё большего числа задач: тестирования, безопасности, эксплуатации, релизов и т. п. Хотя раннее подключение QA и security полезно, но на практике это нередко превращает инженеров в перегруженных «универсалов».
Вместо этого он предлагает «shift down» подход : передавать сложность вниз, на управляемые платформы и абстракции. | 4 520 |
| 18 | 30 сентября в Санкт-Петербурге пройдет легендарная конференция по информационной безопасности - ZeroNights!
На сайте доступна программа, а наша команда Luntry будет рада видеть вас на своей зоне и поболтать на тему безопасности контейнеров и Kubernetes! И мы рады запустить еще один конкурс с проходной на конференцию.
Конкурс: "Самая опасная уязвимость в Kubernetes"
Предыстория: На мой взгляд на текущий момент самой критичной уязвимостью найденной в Kubernetes является CVE-2018-1002105 в kube-apiserver, которая позволяла по итогу обход механизма авторизации!
Задание: Придумайте, какая уязвимость в Kubernetes могла бы по критичности быть на том же уровне или еще выше ;)
Критерий оценки:
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября | 3 331 |
| 19 | Свежевышедшая версия Cilium 1.20 заметно расширяет роль 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 в остальном кластере. | 3 530 |
| 20 | На прошлой неделе мы писали пост про выход новой версии Kyverno, где была закрыта одна серьезная уязвимость. И так получилось, что автор этой находки наш читатель и автор еще многих интересных находок в cloud native проектах: Vault Secrets Operator, Capsule, Strimzi operator, Grafana operator, Fluent Operator, VictoriaMetrics Operator и еще ряда других, которые находятся в процессе исправления. Если вам интересна данная тематика, то можно следить за ними в блоге автора и его канале. Ну и вы можете заметить, что без помощи LLM тут не обходится =) | 3 344 |
