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 103 subscribers, ranking 9 347 in the Technologies & Applications category and 49 199 in the Russia region.
📊 Audience metrics and dynamics
Since its creation on невідомо, the project has demonstrated rapid growth, gathering an audience of 13 103 subscribers.
According to the latest data from 15 September, 2026, the channel demonstrates stable activity. Although there has been a change in the number of participants by 120 over the last 30 days and by 6 over the last 24 hours, overall reach remains high.
- Verification status: Not verified
- Engagement rate (ER): The average audience engagement rate is 28.41%. Within the first 24 hours after publication, content typically collects 13.07% reactions from the total number of subscribers.
- Post reach: On average, each post receives 3 722 views. Within the first day, a publication typically gains 1 712 views.
- Reactions and interaction: The audience actively supports content: the average number of reactions per post is 21.
- 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 16 September, 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.
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 тут не обходится =)12–13 октября в Санкт-Петербурге пройдет конференция DevOops 2026! Вся программа и активности уже доступны на сайте мероприятия. При этом есть прекрасная возможность выиграть билет в рамках нашего конкурса =)
Конкурс: "Самый желанный доклад".
Задание: Придумайте название и описание доклада про Kubernetes (если будет еще связано с ИБ, то здорово) ради которого вы бы 100% посетили бы конференцию, чтобы его послушать. Варианты пишите в комментарии к данному посту.
Критерий оценки :
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября
Всем хороших выходных!apiCall в namespaced Policy обойти namespace isolation и выполнить POST запрос от имени ServiceAccount Kyverno, вплоть до создания MutatingWebhookConfiguration и повышения привилегий до cluster-admin. Уязвимость имеет CVSS 9.9.
GHSA-c5qq-7g2q-cpqp позволяет через percent-encoded `..` обойти проверку namespace и читать ресурсы за его пределами, а исправление для GHSA-q825-p383-r9v5 устраняет SSRF в legacy apiCall, который мог использоваться для доступа к cloud metadata и внутренним сервисам с токеном Kyverno.
Также исправлены GHSA-59v6-2x73-wfg4, позволяющая namespaced policy читать cross-namespace данные через globalcontext.Lib, и GHSA-5cjf-wwfg-pj4c, позволяющая через PolicyException обойти проверку подписей образов в ImageValidatingPolicy.
Для всех пяти advisories CVE пока не назначены.Audit Policy. Она позволит избежать очень популярные ошибки при написании политики аудита в Kubernetes. Самое важно тут, что стоит помнить всегда, что правила применяются сверху в низ и их надо писать от частного к общему! Если вы вообще не понимаете, о чем идет речь, то перед этим изучите материал «Kubernetes Audit Log на страже безопасности кластеров».
Спасибо автору, что поделился своей работой и готов в комментариях по отвечать на любые вопросы по статье ;)АОТ. В этом году она уже будет второй раз и пройдет 22 октября.
До окончания приема заявок осталось совсем немного времени!
Подать заявку на доклад можно тут.eBPF-based runtime security агент, который использует BPF LSM для блокировки нежелательных файловых и сетевых операций непосредственно на уровне ядра Linux. В отличие от инструментов, ориентированных в первую очередь на обнаружение, AegisBPF делает акцент именно на enforcement. Jперация может быть остановлена через -EPERM ещё до завершения syscall.
Также из интересного – поддержка inode-based правил и обработка OverlayFS copy-up, что особенно актуально для контейнеров. Проект умеет применять сетевые deny-правила для IPv4/IPv6, портов и CIDR, а политики можно ограничивать конкретными cgroup.
Отдельно стоит обратить внимание на aegis-next — исследовательский прототип с BPF arena, provenance-графами и дополнительными механизмами enforcement. Проект пока молодой и активно развивается, но выглядит интересно для тех, кто исследует runtime security Linux и Kubernetes через eBPF.Kubernetes появилась статья "Kubernetes v1.37: KubeletInUserNamespace (aka Rootless mode) Graduates to Beta".
Если кто не знал, то благодаря KubeletInUserNamespace все компоненты k8s на Node можно запустить от non-root пользователя, используя Linux user namespace, что уменьшает радиус поражения при побеге из контейнера через эти компоненты (ядро не считается). Это еще один долгострой, работа над которым началась в 2018 и первые плоды появились в Kubernetes v1.22 (2021), теперь осталось дождаться перехода в GA.
И не путайте это с UserNamespaces для Pods, который достиг GA в 1.36 (писали об этом тут и тут).Kubernetes TUI на Rust, который позиционируется как переосмысление k9s. Главная идея — единый пайплайн работы с Kubernetes-ресурсами, благодаря чему CRD поддерживаются без отдельного интерфейса, а Flux CD интегрирован прямо в TUI.
Помимо привычного просмотра Pod’ов, логов и YAML, есть command palette, работа с namespace, Helm и встроенные операции Flux. Интерфейс асинхронный и не блокируется при проблемах или задержках Kubernetes API.
Есть read-only режим, проверки авторизации перед действиями, предупреждения о мутациях управляемых ресурсов и локальный журнал действий.self-host симулятор экзаменов по сдаче Certified Kubernetes Security Specialist (CKS) и Certified Kubernetes Administrator (CKA).
Всем, хороших выходных!Kubernetes Service Accounts для аутентификации запросов между микросервисами без отдельного OAuth-сервера. Идея в том, что сервис получает свой Service Account token, передаёт его вызываемому сервису, а тот проверяет токен через Kubernetes TokenReview API.
Особенно интересен подход с audience-bound projected Service Account tokens. Токен становится ограниченным конкретной аудиторией и имеет короткий срок жизни. При этом RBAC позволяет отдельно определить, какие действия сам сервис может выполнять через Kubernetes API, а system:auth-delegator даёт минимальные права для проверки чужих токенов.
Это хороший пример того, как встроенные механизмы Kubernetes можно использовать для workload identity и service-to-service authentication. При этом автор отдельно подчёркивает, что аутентификация не заменяет шифрование трафика, поэтому для защиты канала всё равно нужен TLS/mTLS.Kubernetes.
P.S. А в 11:00 не забываем про наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред" ;)LLM внутри классического контейнера (считай на базе runc) совершить из него побег.
Сразу стоит отметить, что модель заведомо помещается в так скажем плохо сконфигурированное или уязвимое окружение, тоесть:
- BAD Pods
- уязвимый runc
- уязвимое ядро хостовой ОС
- привилегированный service account в k8s
Всего таких сценариев 18 и все они доступны (отличная база и для CTF и для собственного обучения)! И, конечно, думаю и для многих очевидно, что при таких исходных условиях все 18 сценариев были успешно реализованы.
Тут интересно сколько времени уходили у LLM на тот или и ной сценарий - разброс составляет от нескольких минут до 2 часов. У кого SOC увидит и успеет отреагировать?)
P.S. Насколько я понял тест когда запускали LLM в контейнере без явно заложенных обще известных проблем, то побега не было.cri-o исправили две уязвимости, одна из которых имеет критический уровень и может привести к побегу из контейнера. CVE-2026-62146 позволяет пользователю с правом создавать Pods отравить сохранённое состояние sandbox через произвольные annotations, а после рестарта CRI-O или перезагрузки ноды — добиться монтирования контролируемых host paths и получить доступ к crio.sock.
Вторая уязвимость, CVE-2026-17113, позволяет вызвать падение CRI-O через специально сформированный OCI image с некорректной переменной окружения. Через стандартный Kubernetes API сценарий не эксплуатируется, поскольку kubelet добавляет переменные окружения по умолчанию, но риск остаётся для прямых клиентов.
Исправления доступны в CRI-O 1.34.12, 1.35.7 и 1.36.4. Для CVE-2026-62146 после обновления разработчики также рекомендуют удалить все запущенные контейнеры на нодах.3 исследования:
1) Исследование рынка безопасной разработки и DevSecOps
2) Исследование рынка средств контейнеризации
3) Исследование рынка безопасности ИИ-систем (MLSecOps)
По сути это опросы, результаты которых должны показать реальное (не маркетинговое) положения дел в этих направлениях. Мы с радостью поддерживаем их в этой активности!
Больше деталей можно узнать тут.CVE-2026-31431 (писали о ней тут и тут) в рамках ее эксплуатации в Kubernetes c разными механизмами защиты. Из нее можно узнать, что:
- Pod без root прав,
- Pod с отключёнными capability,
- Pod c RuntimeDefault профилем для seccomp,
- Pod c Pod Security Standards в режиме Restricted,
Все равно может быть проэксплуатирован через CVE-2026-31431 ...
В качестве тестовых окружений исследователи взяли (не не пойми что): OS Talos и EKS на Amazon Linux.
Спасти нас тут могут специально созданный seccomp профиль и обновление самого ядра.
P.S. Еще авторы игрались с `allowPrivilegeEscalation`, но не особо понятно зачем ведь вместо поднятия привилегий внутри контейнера мы просто уходим с него на хост ...Kubernetes 1.37 под кодовым названием «Garhwal». Среди наиболее интересного — manifest-based admission control, который позволяет загружать admission policies с диска и применять их уже при старте API server, даже если etcd недоступен. Для security аудитории также стоит отметить стабильные Pod Certificates и ClusterTrustBundles, а также улучшения SELinux и защиту API server от всплесков нагрузки при инициализации watch cache.
Отдельно интересны Memory QoS на cgroups v2, workload-aware preemption и развитие DRA — включая device taints, extended resources и поддержку ResourceClaims для workloads. В Alpha появился Pod-level checkpoint/restore, а для AI/ML-нагрузок развивается CompositePodGroup и multi-level gang scheduling.3 сентября в 11:00 посетить наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред". Там мы расскажем:
1) Что нового в релизе 4.6
2) Разберем новые инструменты для защиты инфраструктуры
3) Поговорим о практическом применении
4) Планы Luntry до конца года
5) Ответим на технические вопросы
Ссылка для регистрации.