uz
Feedback

Firibgarlarga uchmang! Telemetrio bunday kanallarni topadi va belgilaydi 👉 Belgini ko‘rmoqchi bo‘lsangiz, obuna bo‘ling 👈

k8s (in)security

k8s (in)security

Kanalga Telegram’da o‘tish

Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission

Ko'proq ko'rsatish

📈 Telegram kanali k8s (in)security analitikasi

k8s (in)security (@k8security) Rus til segmentidagi kanali faol ishtirokchi. Hozirda hamjamiyat 13 212 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 9 195-o'rinni va Rossiya mintaqasida 48 234-o'rinni egallagan.

📊 Auditoriya ko‘rsatkichlari va dinamika

невідомо sanasidan buyon loyiha tez o‘sib, 13 212 obunachiga ega bo‘ldi.

07 Oktabr, 2026 dagi oxirgi ma’lumotlarga ko‘ra kanal barqaror faollikka ega. Oxirgi 30 kunda obunachilar soni 120 ga, so‘nggi 24 soatda esa 8 ga o‘zgardi va umumiy qamrov yuqori darajada qolmoqda.

  • Tasdiqlash holati: Tasdiqlanmagan
  • Jalb etish (ER): Auditoriya o‘rtacha 28.86% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 11.95% ini tashkil etuvchi reaksiyalarni to‘playdi.
  • Post qamrovi: Har bir post o‘rtacha 3 810 marta ko‘riladi; birinchi sutkada odatda 1 577 ta ko‘rish yig‘iladi.
  • Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 18 ta reaksiya keladi.
  • Tematik yo‘nalishlar: Kontent kubernetes, контейнер, luntry, кластер, kyverno kabi asosiy mavzularga jamlangan.

📝 Tavsif va kontent siyosati

Muallif resursni shaxsiy fikrni ifoda etish maydoni sifatida ta’riflaydi:
“Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce&registryType=bloggersPermission”

Yuqori yangilanish chastotasi (oxirgi ma’lumot 08 Oktabr, 2026 da olingan) sababli kanal doimo dolzarb va katta qamrovli bo‘lib qoladi. Analitika auditoriya kontent bilan faol hamkorlik qilishini, uni Texnologiyalar & Aralashmalar toifasidagi muhim ta’sir nuqtasiga aylantirishini ko‘rsatadi.

13 212
Obunachilar
+824 soatlar
+217 kun
+12030 kun
Obunachilarni jalb qilish
Okt '26
Oktabr '26
+49
1 kanalda
Sentabr '26
+231
4 kanalda
Get PRO
Avgust '26
+197
5 kanalda
Get PRO
Iyul '26
+208
6 kanalda
Get PRO
Iyun '26
+165
5 kanalda
Get PRO
May '26
+288
5 kanalda
Get PRO
Aprel '26
+216
2 kanalda
Get PRO
Mart '26
+260
8 kanalda
Get PRO
Fevral '26
+195
3 kanalda
Get PRO
Yanvar '26
+171
0 kanalda
Get PRO
Dekabr '25
+183
3 kanalda
Get PRO
Noyabr '25
+163
2 kanalda
Get PRO
Oktabr '25
+151
0 kanalda
Get PRO
Sentabr '25
+148
4 kanalda
Get PRO
Avgust '25
+228
2 kanalda
Get PRO
Iyul '25
+228
10 kanalda
Get PRO
Iyun '25
+182
1 kanalda
Get PRO
May '25
+234
5 kanalda
Get PRO
Aprel '25
+270
4 kanalda
Get PRO
Mart '25
+423
21 kanalda
Get PRO
Fevral '25
+289
3 kanalda
Get PRO
Yanvar '25
+263
4 kanalda
Get PRO
Dekabr '24
+229
5 kanalda
Get PRO
Noyabr '24
+286
3 kanalda
Get PRO
Oktabr '24
+342
13 kanalda
Get PRO
Sentabr '24
+344
10 kanalda
Get PRO
Avgust '24
+387
3 kanalda
Get PRO
Iyul '24
+296
6 kanalda
Get PRO
Iyun '24
+369
4 kanalda
Get PRO
May '24
+261
6 kanalda
Get PRO
Aprel '24
+320
7 kanalda
Get PRO
Mart '24
+334
8 kanalda
Get PRO
Fevral '24
+319
7 kanalda
Get PRO
Yanvar '24
+357
9 kanalda
Get PRO
Dekabr '23
+366
7 kanalda
Get PRO
Noyabr '23
+287
6 kanalda
Get PRO
Oktabr '23
+223
4 kanalda
Get PRO
Sentabr '23
+341
0 kanalda
Get PRO
Avgust '23
+776
0 kanalda
Get PRO
Iyul '23
+175
0 kanalda
Get PRO
Iyun '23
+408
0 kanalda
Get PRO
May '23
+329
0 kanalda
Get PRO
Aprel '23
+219
0 kanalda
Get PRO
Mart '23
+155
0 kanalda
Get PRO
Fevral '23
+146
0 kanalda
Get PRO
Yanvar '23
+123
0 kanalda
Get PRO
Dekabr '22
+107
0 kanalda
Get PRO
Noyabr '22
+154
0 kanalda
Get PRO
Oktabr '22
+174
0 kanalda
Get PRO
Sentabr '22
+195
0 kanalda
Get PRO
Avgust '22
+157
0 kanalda
Get PRO
Iyul '22
+151
0 kanalda
Get PRO
Iyun '22
+274
0 kanalda
Get PRO
May '22
+135
0 kanalda
Get PRO
Aprel '22
+162
0 kanalda
Get PRO
Mart '22
+130
0 kanalda
Get PRO
Fevral '22
+131
0 kanalda
Get PRO
Yanvar '22
+208
0 kanalda
Get PRO
Dekabr '21
+134
0 kanalda
Get PRO
Noyabr '21
+190
0 kanalda
Get PRO
Oktabr '21
+198
0 kanalda
Get PRO
Sentabr '21
+131
0 kanalda
Get PRO
Avgust '21
+130
0 kanalda
Get PRO
Iyul '21
+176
0 kanalda
Get PRO
Iyun '21
+271
0 kanalda
Get PRO
May '21
+121
0 kanalda
Get PRO
Aprel '21
+114
0 kanalda
Get PRO
Mart '21
+253
0 kanalda
Get PRO
Fevral '21
+85
0 kanalda
Get PRO
Yanvar '21
+68
0 kanalda
Get PRO
Dekabr '20
+932
0 kanalda
Sana
Obunachilarni jalb qilish
Esdaliklar
Kanallar
08 Oktabr+7
07 Oktabr+9
06 Oktabr+5
05 Oktabr+6
04 Oktabr+3
03 Oktabr+5
02 Oktabr+6
01 Oktabr+8
Kanal postlari
В 2014 году Google явил миру оркестратор Kubernetes, чтобы управлять множеством контейнеров на множестве хостов, и который сегодня стал стандартом де-факто в индустрии. И уже в 2026 году Google явил миру оркестратор ax (agent executor), чтобы управлять множеством автономных агентов в кластере Kubernetes. Станет ли он стандартом де-факто в индустрии покажет лишь время. AX — это инфраструктура для запуска ИИ нагрузок и работает это дело по верх k8s и Agent Substrate. В его основе три сущности (YAML): 1) Task — задача в изолированной среде: образ контейнера, команда, переменные окружения, запросы и лимиты вычислительных ресурсов. 2) Workspace — рабочее окружение: Git-репозитории, MCP-серверы и пакеты навыков. Можно задать цель обычным языком, например «подготовить Go toolchain», и агент займётся настройкой окружения перед запуском основной команды. 3) Model — конфигурация провайдера и модели, параметры генерации и ссылки на Kubernetes Secrets с учётными данными. Когда агентов становится много, недостаточно просто отправлять запросы к LLM. Нужно воспроизводимо готовить окружения, ограничивать ресурсы, изолировать выполнение и разбираться, почему конкретная задача зависла. AX пытается вынести эту инфраструктурную работу в отдельный слой.

2
NCC Group рассказали, как с помощью LLM-assisted pipeline нашли две уязвимости в etcd. В результате исследования обнаружили C
NCC Group рассказали, как с помощью LLM-assisted pipeline нашли две уязвимости в etcd. В результате исследования обнаружили CVE-2026-59818 — обход проверки отозванных сертификатов на gRPC listener, и CVE-2026-73499 — обход RBAC в Watch API, позволяющий получать события по ключам за пределами выданных прав. Интересно здесь не только сами уязвимости, но и подход к их поиску. LLM анализировал структурированный граф кода, сравнивал связанные execution paths и искал различия в применении security controls, после чего найденные гипотезы проверялись на реальных инстансах etcd. При этом авторы подчёркивают, что LLM генерировал много false positives, поэтому ключевым этапом оставалась динамическая проверка и ручная валидация. Получился довольно показательный пример того, как LLM можно использовать не вместо исследователя, а для значительного расширения покрытия при поиске уязвимостей в больших кодовых баз.
1 490
3
Сегодня мы также хотим поделиться с вами нашим большим внутренним праздником) Наше решение Luntry получило сертификат ФСТЭК!
Сегодня мы также хотим поделиться с вами нашим большим внутренним праздником) Наше решение Luntry получило сертификат ФСТЭК! Мы с 2021 года занимаемся безопасностью контейнеров и Kubernetes, и стараемся каждый год двигать нашу индустрию вперед (решением, этим каналом, нашей конференцией БеКон) и данное событие является еще одним таким шагом. Это был трудный и долгий путь, где вся наша команда вложила много сил и времени. Подробности можно почитать тут - а мы праздновать =) P.S. Больше технических деталей в докладе «ФСТЭК и контейнеры: от заявки до сертификата» с БеКон 2026
1 843
4
Сегодня в центре нашего внимания свежий вайтпейпер "Kubernetes Misconfigurations in the Wild: Taxonomy, Evolution, and Automa
Сегодня в центре нашего внимания свежий вайтпейпер "Kubernetes Misconfigurations in the Wild: Taxonomy, Evolution, and Automated Repair with Large Language Models" Где авторы исследуют два вопроса: 1) какие ошибки конфигурации чаще всего возникают на практике; 2) насколько хорошо LLM могут автоматически их исправлять. Для этого они анализируют обсуждения разработчиков на Stack Overflow, Helm-чарты и результаты нескольких инструментов статического анализа. По первому моменту они сделали таксономию из 5 основных разделов (ее можно видеть на скриншоте). А по второму итоговый вывод в том, что LLM лучше использовать не как полностью автономную сущность, а как генератор исправления, работающий внутри конвейера с детерминированной валидацией. Тоесть гибрид LLM + schema/policy validation выглядит значительно надёжнее (98–99% корректных исправлений), чем “чистая” генерация исправлений, но до безопасного автопилота ещё далеко. Все смотрелось только в статике, итоговые исправления не запускались на практике, да и явно что в выборке по Stack Overflow и Helm-чартам далеко не все классы проблем присутствуют.
4 155
5
Исследователи Palo Alto Networks показали интересный сценарий атаки на SPIFFE/SPIRE в Kubernetes. Если атакующий получает roo
Исследователи 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 153
6
k8s-aibom - это оператор для сбора AI Bill of Materials в Kubernetes. В AI-проектах уже недостаточно знать только версии конт
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 458
7
Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, как
Docker Sandbox Kit Specification — это открытая спецификация упаковки окружения для AI-агентов вместе с декларацией того, какие доступы ему нужны. Dockerfile описывает, что установлено внутри образа. Kit дополнительно описывает, что этому окружению потребуется снаружи: сеть, учётные данные, хранилища, инструменты и контекст для агента. При этом Kit сам ничего не разрешает: он запрашивает возможности, а среда запуска решает, что предоставить, и обеспечивает ограничения. Kit собирает программное окружение и декларации его потребностей в один версионируемый артефакт. Он представляет собой технически обычный OCI-образ с дополнительной аннотацией. Обеспечивать заявленные ограничения должен Kit-совместимый runtime. Но формат не ограничен агентами: им можно описывать потребности обычных сервисов! По сути Docker Sandbox Kit — это переносимый комплект окружения плюс явный список его запросов к внешнему миру. Как попробовать на практике? Самый понятный путь — установить sbx runtime и запустить локальные примеры из репозитория. P. S. Важная оговорка: спецификация сейчас экспериментальная, финальная версия в README намечена на IV квартал 2026 года.
2 936
8
Docker выпустил свой официальный набор skills для работы со своими решениями: - Dockerfile & Build - Docker Compose - Docker Sandboxes - Docker Agent - Cross-Product В общем если вы активно работаета с Docker и Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI, OpenCode и т.д. то это может вам пригодиться.
3 604
9
Сегодняшний наш герой это 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 308
10
Сконцентрировавшись на серверной части инфраструктуры, мы порой непростительно забываем про клиентскую историю. Так вот очередная уязвимость в 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 738
11
Начнем неделю со статьи "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 677
12
В 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 724
13
Цикл статей "User Namespaces in Kubernetes": 1) Part I: All You Need to Know 2) Part II: Mappings and File Ownership 3) Part
Цикл статей "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 568
14
Из статьи "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 653
15
В официальном блоге Kubernetes появилась заметка "Kubernetes v1.37: Hardening Container Storage with Bind Mount Options and E
В официальном блоге 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 395
16
Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать AI-агенты, AI сгенерированный код. Мы также уже
Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать 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 433
17
Итоги конкурсов! Конкурс: "Самый желанный доклад". Победитель @Nuclearm С докладом про «как мы выпилили k8s и стали спать по ночам: история одного отказоустойчивого монолита». хочу услышать, как команда решилась и что потеряла. Конкурс: "Самая опасная уязвимость в Kubernetes" Победитель @pharma_unsafe С багой в драйвере Поздравляем победителей! Победителям отдельно напишем в ЛС и расскажем как получить проходки.
3 856
18
Если UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит: 1) server room 2) the rack =) Всем
Если UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит: 1) server room 2) the rack =) Всем хороших выходных! P.S. Результаты конкурсов объявим в 18:00 по Мск.
4 084
19
Завтра последний день, чтобы поучаствовать в конкурсах и выиграть проходку на: 1) DevOops 2026 - участвовать! 2) ZeroNights 2026 - учувствовать! еще есть время ;)
3 936
20
Наша команда R&D обнаружила критическую уязвимость в NeuVector — CVE-2026-78424. Проблема находится в механизме packet captur
Наша команда 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 199