uz
Feedback
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 12 819 obunachidan iborat bo'lib, Texnologiyalar & Aralashmalar toifasida 9 862-o'rinni va Rossiya mintaqasida 51 363-o'rinni egallagan.

📊 Auditoriya ko‘rsatkichlari va dinamika

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

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

  • Tasdiqlash holati: Tasdiqlanmagan
  • Jalb etish (ER): Auditoriya o‘rtacha 26.01% darajada jalb etiladi. Nashrdan keyingi dastlabki 24 soatda kontent odatda umumiy obunachilar sonining 13.21% ini tashkil etuvchi reaksiyalarni to‘playdi.
  • Post qamrovi: Har bir post o‘rtacha 3 334 marta ko‘riladi; birinchi sutkada odatda 1 693 ta ko‘rish yig‘iladi.
  • Reaksiyalar va o‘zaro ta’sir: Auditoriya faol: har bir postga o‘rtacha 20 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 27 Iyun, 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.

12 819
Obunachilar
+324 soatlar
+237 kunlar
+5630 kunlar
Postlar arxiv
C 18 июня сдача экзамена CKS (Certified Kubernetes Security Specialist) или его продление автоматически восстанавливает и про
C 18 июня сдача экзамена CKS (Certified Kubernetes Security Specialist) или его продление автоматически восстанавливает и продлевает сертификацию CKA (Certified Kubernetes Administrator). Дата истечения CKA теперь подтягивается к дате нового CKS — причём это работает даже если ваш CKA уже просрочен. По сути один успешный экзамен поддерживает обе сертификации актуальными. CKS строится на знаниях и навыках CKA, так что прохождение CKS уже служит подтверждением базовых административных компетенций. Никаких дополнительных действий не требуется — после сдачи или продления CKS дата CKA обновится сама. Особенно это удобно для Kubestronaut'ов, которым нужно держать активными сразу пять сертификаций Kubernetes.

Наверное правильнее было бы этот пост сделать в пятницу, ну ладно) webernetes - Kubernetes в web-браузере. Вы спросите зачем
Наверное правильнее было бы этот пост сделать в пятницу, ну ладно) webernetes - Kubernetes в web-браузере. Вы спросите зачем такое вообще? В общем, ребятам для обучающих целей не хочется держать и поднимать реальную инфраструктуру и они пошли по пути browser-based симулятора =) Live Demo.

Контейнеры не изолируют приложения магически — за этим стоят конкретные механизмы Linux ядра: пространства имён, capabilities и bind mounts. Доклад "Know "Con Fu"! Container security techniques and the Canon of eBPF" разбирает эти механизмы с нуля, от базовых принципов до продвинутых техник. Райнхард Коглер показывает обе стороны медали: как атакующий использует особенности ядра для побега из контейнера и как защитник применяет те же знания для обнаружения и блокировки угроз. Ценность доклада в системном подходе: понять контейнерную безопасность по-настоящему можно только разобравшись, как Linux работает под капотом. Обязательный материал для всех, кто эксплуатирует Docker или Kubernetes в продакшене.

В 2026 году очень сложно удивить каким-либо способом доставки secret до приложения. Особенно это сложно с учетом доклада Вале
В 2026 году очень сложно удивить каким-либо способом доставки secret до приложения. Особенно это сложно с учетом доклада Валеры Кунавина "От стандартных к нестандартным методам управления секретами в контейнерах" с конференции БеКон 2024. НО сегодняшнему герою как мне кажется это удалось сделать. Kloak - инструмент, который с помощью eBPF uprobes перехватывает исходящий TLS-трафик в Kubernetes, заменяя хешированные placeholders реальными секретами на уровне ядра перед шифрованием. Приложения никогда не обрабатывают фактические учетные данные, и не требуется никаких sidecar-контейнеров или изменений в коде. Проект поддерживает: - Хуки в OpenSSL, BoringSSL и нативном Go crypto/tls. - Работу с Python, Node.js, Go, Rust, Ruby, PHP, curl и любым OpenSSL-linked runtime.

Сontainerd выпустил патчи для пяти уязвимостей, и четыре из них связаны с одним механизмом — восстановлением контейнеров из c
Сontainerd выпустил патчи для пяти уязвимостей, и четыре из них связаны с одним механизмом — восстановлением контейнеров из checkpoint образов в CRI-плагине. Самые опасные позволяют через недоверенный checkpoint-образ прочитать произвольный файл на хосте по символической ссылке (CVE-2026-53489), протащить CDI-аннотации и получить доступ к устройствам хоста (CVE-2026-53492), а также подменить локальные теги образов (CVE-2026-50195). Отдельно стоит уязвимость CVE-2026-53488: метки из конфига образа (инструкция LABEL в Dockerfile) пробрасываются в контейнер без валидации, что в итоге может привести к выполнению команд от root прямо на хосте при простом pull образа. Пятая (CVE-2026-47262) — это DoS: специально собранный образ вызывает исчерпание памяти и OOM-kill процесса containerd, выводя из строя весь runtime API. Обновляйтесь до 2.3.2, 2.2.5, 2.1.9, 2.0.10 или 1.7.33, а до обновления используйте только проверенные образы и ограничьте круг тех, кто может импортировать образы или запускать поды.

Ото дня ко дню все чаше в инфо поле мелькают AI агенты и AI сгенерированный код. Который по сути равносилен не доверенному коду. Мы писали уже об этом (1,2,3,4). Но так или иначе надо этот код запускать и обеспечивать его изоляцию и безопасность. Так что не удивительно что под такую специфичную задачу появляются и специализированные/заточенные решения. На пример, проект Isola. Это проект с открытым исходным кодам как раз для запуска такой AI не доверенной нагрузки в кластере Kubernetes с использованием gVisor рантайма для изоляции от ядра хостовой ОС. при этом система декларативно через Custom Resources позволяет управлять как самими sandboxes, так и snapshots файловой системы (для прогретого запуска). А сетевая изоляция реализована с помощью классического ресурса NetworkPolicy, тоесть тоже декларативно и максимально удобно. P.S. При желании вам никто не мешает собрать/добавить подобное в свой ванильный кластер ;)

Инженеры DoubleVerify рассказали, как собирать метрики производительности из приложений, развёрнутых в инфраструктуре партнёр
Инженеры DoubleVerify рассказали, как собирать метрики производительности из приложений, развёрнутых в инфраструктуре партнёров, которая остаётся для них «чёрным ящиком». Решением стал Vector от Datadog — лёгкий open-source инструмент для сбора, преобразования и маршрутизации логов, метрик и трейсов в любые системы мониторинга. Авторы показывают пошаговую настройку взаимной аутентификации mTLS между Vector и удалённым Prometheus с помощью самоподписанных сертификатов, что гарантирует подлинность обеих сторон соединения. Vector разворачивается в Kubernetes как StatefulSet. При этом инструмент гибок и поддерживает разные схемы развёртывания, а также работу с Loki, Splunk и Datadog помимо Prometheus.

Как-то так получилось, что за все время существование канала мы не писали о таком проекте как Darp (Distributed Application R
Как-то так получилось, что за все время существование канала мы не писали о таком проекте как Darp (Distributed Application Runtime). По сути это универсальный runtime-слой для микросервисов и event-driven приложений, который делает распределённую разработку проще, переносимее и менее зависимой от конкретной инфраструктуры. В отличие от service mesh вроде Istio или Linkerd, Dapr ориентирован не только на сетевое взаимодействие, а на прикладные building blocks: state, pub/sub, bindings, actors, workflows. Service mesh решает в основном задачи трафика, безопасности и observability между сервисами. В отличие от Spring Cloud, Micronaut или других framework-based решений, Dapr не требует писать приложение на конкретном языке или фреймворке. Он работает с любым языком, потому что предоставляет внешние HTTP/gRPC API. В отличие от SDK для облачных сервисов, Dapr даёт абстракцию над провайдерами. Можно заменить Redis на PostgreSQL, Kafka на RabbitMQ или Azure Service Bus без серьёзного изменения бизнес-кода. В отличие от Kubernetes-native операторов, Dapr не только управляет инфраструктурой, но и предоставляет runtime API, с которым напрямую взаимодействует приложение. P.S. Есть кто его использует?

ClusterHound — это инструмент, который встраивает Kubernetes в BloodHound. С помощью kubectl он собирает топологию кластера и
ClusterHound — это инструмент, который встраивает Kubernetes в BloodHound. С помощью kubectl он собирает топологию кластера и его RBAC-конфигурацию, после чего выгружает результат в OpenGraph JSON для импорта. Главная идея в том, что многошаговые цепочки атак в Kubernetes — захват сервис-аккаунтов, эскалация привилегий, побег с хоста, доступ к секретам — превращаются в проходимые рёбра графа, по которым можно строить маршруты атак. Под капотом кластер моделируется как 15 типов узлов и 27 типов рёбер, а рёбра отдаются как structured graph, который нативно понимает встроенный pathfinding BloodHound. В комплекте идёт 31 готовый Cypher-запрос — от анализа точек входа до кратчайших путей до полной компрометации кластера. Инструмент работает только на чтение (get/list) и мапит ровно столько, сколько видят используемые учётные данные, поэтому его можно запускать как на весь кластер, так и в рамках отдельных namespace. Требуется Python 3.8+, kubectl и BloodHound CE версии 9.0 и выше. Проект активно развивается.

Компания Microsoft продолжает развивать Linux подсистему в рамках своей Windows и в этом можно убедиться в рамках нового докл
Компания Microsoft продолжает развивать Linux подсистему в рамках своей Windows и в этом можно убедиться в рамках нового доклада "WSL improvements and the new Containers CLI and APIs". И да, тему контейнеров там они тоже улучшают! Из данного доклада вы узнаете: 1) Общее назначение 2) Появление CLI утилиты WSLC для управление контейнерами 3) Сборка Custom Images 4) Появление NuGet-based API для взаимодействие по API с теме же Windows приложениями 5) WSL Containers SDK 6) Про архитектуру Все это демонстрируется с примерами и в основном упор на AI, ML, GPU тасках (ну понятно куда все это идет). В общем, это отличный вариант изолированно запускать агентов и выдавать им ограниченный доступ у себя на Windows машине.

В свежем посте Solving secret sprawl in multi-account Kubernetes with External Secrets Operator в блоге CNCF разбирают типичн
В свежем посте Solving secret sprawl in multi-account Kubernetes with External Secrets Operator в блоге CNCF разбирают типичную боль multi-account Kubernetes: окружения dev/staging/prod изолированы по разным аккаунтам и кластерам, и общие секреты приходится вручную дублировать и обновлять в каждом из них. Авторы решили проблему связкой External Secrets Operator и Bitwarden Secrets Manager: секреты хранятся централизованно в одном месте, а ESO в каждом кластере автоматически синхронизирует их в обычные Kubernetes Secrets. Приложения при этом ничего не замечают и продолжают работать со стандартными механизмами, а сам подход provider-agnostic — вместо Bitwarden можно подставить Vault, AWS Secrets Manager или Azure Key Vault. В статье есть пошаговый гайд с манифестами (включая настройку TLS через cert-manager) и ссылка на Terraform автоматизацию. Ключ ротируется один раз в центральном хранилище, и в течение 15 минут все кластеры получают обновление автоматически.

Статья "Mastering Kubernetes Security: A Deep Dive into SecurityContext" очень хорошо с примерами закрывает все вопросы по на
Статья "Mastering Kubernetes Security: A Deep Dive into SecurityContext" очень хорошо с примерами закрывает все вопросы по назначению, устройству, разновидностям SecurityContext. Может быть отличной отправной точкой для начинающих и шпаргалкой для опытных пользователей ;)

Спор о том, действительно ли контейнеры обеспечивают изоляцию, идёт давно, и автор поста Rory McCune считает, что баланс сейч
Спор о том, действительно ли контейнеры обеспечивают изоляцию, идёт давно, и автор поста Rory McCune считает, что баланс сейчас смещается: изоляция Docker-контейнеров всегда была слабее, чем у виртуальных машин из-за большой поверхности атаки ядра Linux, но раньше создание эксплойтов для побега из контейнера требовало редких навыков и много времени. Теперь же LLM-инструменты резко упрощают эту задачу. В качестве примера McCune взял свежую уязвимость локального повышения привилегий CIFSwitch (CVE-2026-46243) и просто передал модели блог-пост и готовый PoC. За два часа и 13 долларов Claude Code самостоятельно собрал рабочий эксплойт для побега из контейнера. Ключевых условия два: достаточно «сговорчивая» модель (автор хвалит Opus 4.6, отмечая, что более поздние версии строже в наступательной безопасности) и цикл валидации, где модель реально тестирует код в одноразовых VM, чтобы не выдавать галлюцинации. По мнению автора, на фоне волны свежих LPE-уязвимостей и такой лёгкости создания эксплойтов стоит пересмотреть надёжность стандартной изоляции контейнеров. Если вы запускаете недоверенные образы или есть риск исполнения кода внутри контейнера, нужно исходить из того, что атакующий сможет вырваться на хост. Это не значит отказаться от контейнеров — лишь сверить их использование со своей моделью угроз.

Вчера (7 июня) исполнилось 12 лет как Kubernetes увидел свет =) По этому поводу вы можете: 1) Посмотреть документальный фильм про k8s 2) Почитать о ключевых датах в его развитии "The History of Kubernetes on a Timeline" Как вы считаете 12 лет это много или мало для технологии/инструмента в IT ?

Inspektor Gadget — open source инструмент на базе eBPF для наблюдаемости в Kubernetes — прошёл первый независимый аудит безоп
Inspektor Gadgetopen source инструмент на базе eBPF для наблюдаемости в Kubernetes — прошёл первый независимый аудит безопасности. Аудит координировал OSTIF, финансировал CNCF, а проводила компания Shielder. Нашли всего три уязвимости, причём ни одной с критическим или высоким уровнем риска: две средних (command injection в сборке образов и DoS через переполнение eBPF ring buffer) и одну низкую (неэкранированные ANSI escape-последовательности в выводе терминала). Самая интересная часть — тесты на обход «гаджетов»: исследователи проверяли, может ли скомпрометированный контейнер выполнять отслеживаемые операции, не вызывая событий. Они нашли шесть таких сценариев — например, использование новых системных вызовов вроде openat2 вместо openat, обход через io_uring и статически слинкованные библиотеки. Это наглядно показывает, что трассировка на уровне ядра — вечная игра в кошки-мышки: Linux эволюционирует, появляются новые syscalls, и eBPF-инструментам приходится постоянно за этим гнаться.

Исследование "Container Escape Paths Nobody Monitors: Abusing Linux Debug Interfaces" с Linux Security Summit рассматривает и
Исследование "Container Escape Paths Nobody Monitors: Abusing Linux Debug Interfaces" с Linux Security Summit рассматривает использование отладочных интерфейсов Linux для побега из контейнера на хост: - ptrace, - perf, - eBPF, - /proc и /sys файловая система. Инструменты, которые разработчики используют ежедневно (strace, gdb, perf), являются мощным оружием в руках атакующего. Злоумышленники могут использовать эти интерфейсы для внедрения кода, перехвата системных вызовов и кражи секретов без необходимости использования уязвимостей (CVE). Ключевым выводом является необходимость перехода от «изоляции представления» к «изоляции безопасности» через минимизацию привилегий и жесткое ограничение интерфейсов отладки в производственных средах. Безопасность контейнеров не ограничивается исправлением известных CVE. Основная угроза часто кроется в легитимных инструментах отладки Linux, которые остаются доступными из-за стандартных или небрежных настроек.

Большое спасибо всем докладчикам, партнерам и коллегам частникам! Без вас не было бы нашей конференции. Увидимся через год ;)

Никита Хренов | Альфа-Банк, переходит к своему докладу - "Оператор Всевластия» для разработки распределенных систем и управления сетевой безопасностью" 📌 Трек Ингредиенты

Максим Василенко | Флант, переходит к своему докладу - "Контроль целостности в Kubernetes по-взрослому" 📌 Трек Ингредиенты

Валерий Кунавин | Ozon Банк, переходит к своему докладу - "Как не убить кластер и безопасность исключениями" 📌 Трек Рецепты