k8s (in)security

В официальном блоге 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.

Все-все-все сейчас озадачены то как и чем лучше всего и надежнее изолировать 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 можно запускать только доверенные приложения )))))) наверное она что-то знает еще)))))

Итоги конкурсов!

Конкурс: "Самый желанный доклад".
Победитель @Nuclearm
С докладом про «как мы выпилили k8s и стали спать по ночам: история одного отказоустойчивого монолита». хочу услышать, как команда решилась и что потеряла.

Конкурс: "Самая опасная уязвимость в Kubernetes"
Победитель @pharma_unsafe
С багой в драйвере

Поздравляем победителей!

Победителям отдельно напишем в ЛС и расскажем как получить проходки.

Если UI ваших Kubernetes платформ выглядит не так, то даже не зовите нас на пентест/аудит:
1) server room
2) the rack

=)

Всем хороших выходных!

P.S. Результаты конкурсов объявим в 18:00 по Мск.

Завтра последний день, чтобы участвовать в конкурсах и выиграть проходку на:
1) DevOops 2026 - участвовать!
2) ZeroNights 2026 - учувствовать!

еще есть время ;)

Наша команда 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.

Я долгое время считал, что подход/термин “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» подход : передавать сложность вниз, на управляемые платформы и абстракции.

30 сентября в Санкт-Петербурге пройдет легендарная конференция по информационной безопасности - ZeroNights!

На сайте доступна программа, а наша команда Luntry будет рада видеть вас на своей зоне и поболтать на тему безопасности контейнеров и Kubernetes! И мы рады запустить еще один конкурс с проходной на конференцию.

Конкурс: "Самая опасная уязвимость в Kubernetes"
Предыстория: На мой взгляд на текущий момент самой критичной уязвимостью найденной в Kubernetes является CVE-2018-1002105 в kube-apiserver, которая позволяла по итогу обход механизма авторизации!
Задание: Придумайте, какая уязвимость в Kubernetes могла бы по критичности быть на том же уровне или еще выше ;)
Критерий оценки:
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября

Свежевышедшая версия 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 в остальном кластере.

На прошлой неделе мы писали пост про выход новой версии Kyverno, где была закрыта одна серьезная уязвимость. И так получилось, что автор этой находки наш читатель и автор еще многих интересных находок в cloud native проектах: Vault Secrets Operator, Capsule, Strimzi operator, Grafana operator, Fluent Operator, VictoriaMetrics Operator и еще ряда других, которые находятся в процессе исправления (Cilium, Tetragon, ArgoCD, Talos Linux и в контейнерных движках). Если вам интересна данная тематика, то можно следить за ними в блоге автора и его канале. Ну и вы можете заметить, что без помощи LLM тут не обходится =)

12–13 октября в Санкт-Петербурге пройдет конференция DevOops 2026! Вся программа и активности уже доступны на сайте мероприятия. При этом есть прекрасная возможность выиграть билет в рамках нашего конкурса =)

Конкурс: "Самый желанный доклад".
Задание: Придумайте название и описание доклада про Kubernetes (если будет еще связано с ИБ, то здорово) ради которого вы бы 100% посетили бы конференцию, чтобы его послушать. Варианты пишите в комментарии к данному посту.
Критерий оценки :
- Реалистичность
- Оригинальность
- Технические детали
Итоги: 18 сентября

Всем хороших выходных!

В новой версии 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 пока не назначены.

Сегодня мы рекомендуем вам ознакомиться со статьей "Аудит-политика Kubernetes: чек-лист против типовых слепых зон в правилах". В рамках данного материала автор отмечает тонкие, но очень важные моменты при составлении и контроле Audit Policy. Она позволит избежать очень популярные ошибки при написании политики аудита в Kubernetes. Самое важно тут, что стоит помнить всегда, что правила применяются сверху в низ и их надо писать от частного к общему! Если вы вообще не понимаете, о чем идет речь, то перед этим изучите материал «Kubernetes Audit Log на страже безопасности кластеров».

Спасибо автору, что поделился своей работой и готов в комментариях по отвечать на любые вопросы по статье ;)

Всем, привет!

Еще есть прекрасная возможность поделиться с коллегами своим опытом и знаниям в рамках выступления на конференции Kuber Conf от АОТ. В этом году она уже будет второй раз и пройдет 22 октября.

До окончания приема заявок осталось совсем немного времени!

Подать заявку на доклад можно тут.

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.

В официальном блоге 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 (писали об этом тут и тут).

P.S. Напоминаем про проект Usernetes, где можно с подобным поиграться.

Sofka — новый Kubernetes TUI на Rust, который позиционируется как переосмысление k9s. Главная идея — единый пайплайн работы с Kubernetes-ресурсами, благодаря чему CRD поддерживаются без отдельного интерфейса, а Flux CD интегрирован прямо в TUI.

Помимо привычного просмотра Pod’ов, логов и YAML, есть command palette, работа с namespace, Helm и встроенные операции Flux. Интерфейс асинхронный и не блокируется при проблемах или задержках Kubernetes API.

Есть read-only режим, проверки авторизации перед действиями, предупреждения о мутациях управляемых ресурсов и локальный журнал действий.

K16S - еще один self-host симулятор экзаменов по сдаче Certified Kubernetes Security Specialist (CKS) и Certified Kubernetes Administrator (CKA).

Всем, хороших выходных!

В статье «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.

Всем, привет!

3 сентября на ИБ Митап в Санкт-Петербурге (давненько здесь не выступал) выступлю с докладом "Устаревшая безопасность, проигранная гонка (?||!)". На мой взгляд это мой самый грустный по настроению и посылу доклад за все время. При этом наверное первый за несколько лет в котором я вообще не говорю слов про контейнеры и Kubernetes.

P.S. А в 11:00 не забываем про наш вебинар "Luntry 4.6: Новые возможности для защиты контейнерных и облачных сред" ;)