k8s (in)security
前往频道在 Telegram
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru #ZST99 Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
显示更多📈 Telegram 频道 k8s (in)security 的分析概览
频道 k8s (in)security (@k8security) 俄语 语言赛道中的 是活跃参与者。目前社区聚集了 13 103 名订阅者，在 技术与应用 类别中位列第 9 347，并在 俄罗斯 地区排名第 49 199 位。
📊 受众指标与增长动态
自 невідомо 创建以来，项目保持高速增长，吸引了 13 103 名订阅者。
根据 15 九月, 2026 的最新数据，频道保持稳定运转。过去 30 天订阅人数变化为 120，过去 24 小时变化为 6，整体触达仍然可观。
- 认证状态： 未认证
- 互动率 (ER)： 平均受众互动率为 28.41%。内容发布后 24 小时内通常能获得 13.07% 的反应，占订阅者总量。
- 帖子覆盖： 每篇帖子平均可获得 3 722 次浏览，首日通常累积 1 712 次浏览。
- 互动与反馈： 受众积极参与，单帖平均反应数为 21。
- 主题关注点： 内容集中在 kubernetes, контейнер, luntry, кластер, kyverno 等核心主题上。
📝 描述与内容策略
作者将该频道定位为表达主观观点的平台：
“Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений.
Ведет команда www.luntry.ru
#ZST99
Вопросы, идеи, предложения => @Qu3b3c
https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission”
凭借高频更新（最新数据采集于 16 九月, 2026），频道始终保持新鲜度与高覆盖。分析显示受众积极互动，使其成为 技术与应用 类别中的关键影响点。
13 103
订阅者
+624 小时
+157 天
+12030 天
帖子存档
13 104
Я долгое время считал, что подход/термин “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» подход : передавать сложность вниз, на управляемые платформы и абстракции.13 104
30 сентября в Санкт-Петербурге пройдет легендарная конференция по информационной безопасности - ZeroNights!
На сайте доступна программа, а наша команда Luntry будет рада видеть вас на своей зоне и поболтать на тему безопасности контейнеров и Kubernetes! И мы рады запустить еще один конкурс с проходной на конференцию.
Конкурс: "Самая опасная уязвимость в Kubernetes"
Предыстория: На мой взгляд на текущий момент самой критичной уязвимостью найденной в Kubernetes является CVE-2018-1002105 в kube-apiserver, которая позволяла по итогу обход механизма авторизации!
Задание: Придумайте, какая уязвимость в Kubernetes могла бы по критичности быть на том же уровне или еще выше ;)
Критерий оценки:
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября13 104
Свежевышедшая версия 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 в остальном кластере.13 104
На прошлой неделе мы писали пост про выход новой версии
Kyverno, где была закрыта одна серьезная уязвимость. И так получилось, что автор этой находки наш читатель и автор еще многих интересных находок в cloud native проектах: Vault Secrets Operator, Capsule, Strimzi operator, Grafana operator, Fluent Operator, VictoriaMetrics Operator и еще ряда других, которые находятся в процессе исправления. Если вам интересна данная тематика, то можно следить за ними в блоге автора и его канале. Ну и вы можете заметить, что без помощи LLM тут не обходится =)13 104
12–13 октября в Санкт-Петербурге пройдет конференция DevOops 2026! Вся программа и активности уже доступны на сайте мероприятия. При этом есть прекрасная возможность выиграть билет в рамках нашего конкурса =)
Конкурс: "Самый желанный доклад".
Задание: Придумайте название и описание доклада про Kubernetes (если будет еще связано с ИБ, то здорово) ради которого вы бы 100% посетили бы конференцию, чтобы его послушать. Варианты пишите в комментарии к данному посту.
Критерий оценки :
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября
Всем хороших выходных!13 104
В новой версии Kyverno 1.19.1 был исправлен ряд уязвимостей. Самая критичная, GHSA-5qq8-67g6-4h2w, позволяет через
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 пока не назначены.13 104
Сегодня мы рекомендуем вам ознакомиться со статьей "Аудит-политика Kubernetes: чек-лист против типовых слепых зон в правилах". В рамках данного материала автор отмечает тонкие, но очень важные моменты при составлении и контроле
Audit Policy. Она позволит избежать очень популярные ошибки при написании политики аудита в Kubernetes. Самое важно тут, что стоит помнить всегда, что правила применяются сверху в низ и их надо писать от частного к общему! Если вы вообще не понимаете, о чем идет речь, то перед этим изучите материал «Kubernetes Audit Log на страже безопасности кластеров».
Спасибо автору, что поделился своей работой и готов в комментариях по отвечать на любые вопросы по статье ;)13 104
Всем, привет!
Еще есть прекрасная возможность поделиться с коллегами своим опытом и знаниям в рамках выступления на конференции Kuber Conf от
АОТ. В этом году она уже будет второй раз и пройдет 22 октября.
До окончания приема заявок осталось совсем немного времени!
Подать заявку на доклад можно тут.13 104
AegisBPF —
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.13 104
В официальном блоге
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 (писали об этом тут и тут).13 104
Sofka — новый
Kubernetes TUI на Rust, который позиционируется как переосмысление k9s. Главная идея — единый пайплайн работы с Kubernetes-ресурсами, благодаря чему CRD поддерживаются без отдельного интерфейса, а Flux CD интегрирован прямо в TUI.
Помимо привычного просмотра Pod’ов, логов и YAML, есть command palette, работа с namespace, Helm и встроенные операции Flux. Интерфейс асинхронный и не блокируется при проблемах или задержках Kubernetes API.
Есть read-only режим, проверки авторизации перед действиями, предупреждения о мутациях управляемых ресурсов и локальный журнал действий.13 104
K16S - еще один
self-host симулятор экзаменов по сдаче Certified Kubernetes Security Specialist (CKS) и Certified Kubernetes Administrator (CKA).
Всем, хороших выходных!13 104
В статье «Authentication between microservices using Kubernetes identities» показано, как использовать
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.13 104
Всем, привет!
3 сентября на ИБ Митап в Санкт-Петербурге (давненько здесь не выступал) выступлю с докладом "Устаревшая безопасность, проигранная гонка (?||!)". На мой взгляд это мой самый грустный по настроению и посылу доклад за все время. При этом наверное первый за несколько лет в котором я вообще не говорю слов про контейнеры и
Kubernetes.
P.S. А в 11:00 не забываем про наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред" ;)13 104
У коллег с прекрасного канала PWN AI узнал про интересную работу "Inspect evaluation: Container sandbox breakout", где исследователи оценивают насколько просто или сложно
LLM внутри классического контейнера (считай на базе runc) совершить из него побег.
Сразу стоит отметить, что модель заведомо помещается в так скажем плохо сконфигурированное или уязвимое окружение, тоесть:
- BAD Pods
- уязвимый runc
- уязвимое ядро хостовой ОС
- привилегированный service account в k8s
Всего таких сценариев 18 и все они доступны (отличная база и для CTF и для собственного обучения)! И, конечно, думаю и для многих очевидно, что при таких исходных условиях все 18 сценариев были успешно реализованы.
Тут интересно сколько времени уходили у LLM на тот или и ной сценарий - разброс составляет от нескольких минут до 2 часов. У кого SOC увидит и успеет отреагировать?)
P.S. Насколько я понял тест когда запускали LLM в контейнере без явно заложенных обще известных проблем, то побега не было.13 104
В свежем релизе
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 после обновления разработчики также рекомендуют удалить все запущенные контейнеры на нодах.13 104
Наши хорошие друзья запустили аж целых
3 исследования:
1) Исследование рынка безопасной разработки и DevSecOps
2) Исследование рынка средств контейнеризации
3) Исследование рынка безопасности ИИ-систем (MLSecOps)
По сути это опросы, результаты которых должны показать реальное (не маркетинговое) положения дел в этих направлениях. Мы с радостью поддерживаем их в этой активности!
Больше деталей можно узнать тут.13 104
В статье "We Tested Copy Fail in Kubernetes: PSS Restricted and RuntimeDefault Did Not Block AF_ALG" детально изучается уязвимость ядра
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`, но не особо понятно зачем ведь вместо поднятия привилегий внутри контейнера мы просто уходим с него на хост ...13 104
Вышел
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.13 104
Всем, привет!
Приглашаем всех
3 сентября в 11:00 посетить наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред". Там мы расскажем:
1) Что нового в релизе 4.6
2) Разберем новые инструменты для защиты инфраструктуры
3) Поговорим о практическом применении
4) Планы Luntry до конца года
5) Ответим на технические вопросы
Ссылка для регистрации.