k8s (in)security

Завтра последний день и последняя возможность подать свою тему доклада на нашу конференцию по БЕзопасности КОНтейнеров и Kubernetes - БеКон!

Доклад How To Break Multi-Tenancy Again and Again ...and What We Can Learn From It - Lorin Lehawany & Sven Nobis, ERNW с недавно прошедшей конференции KubeCon Europe 2026 показывает, что namespace-based multi-tenancy в Kubernetes и Istio, Kubeflow и Traefik системно ломается из-за неверных предположений об изоляции. Основная мысль — namespaces не являются границей безопасности, а многие ресурсы, включая сетевые, действуют на уровне всего кластера или mesh. Это подтверждается и примерами из презентации доклада.

Один из ключевых векторов — Istio VirtualService, который может управлять трафиком за пределами своего namespace, включая сервисы других tenants. Это открывает возможность атак вроде перехвата или перенаправления трафика внутри mesh, что подробно разобрано в рекомендациях Istio. Дополнительно проблема подтверждается опубликованными security advisory Istio, где описаны реальные уязвимости и их влияние.

Очевидно, что namespaces нельзя считать границей доверия, и shared cluster по умолчанию небезопасен. Требуются дополнительные меры: строгий контроль прав, ограничение сетевых ресурсов, использование новых API и пересмотр модели multi-tenancy. Практические примеры атак и конфигураций доступны в репозитории авторов , который хорошо иллюстрирует, как эти проблемы проявляются на практике.

Сегодня в центре нашего внимания исследование «The Kubernetes Security Landscape: AI-Driven Insights from Developer Discussions». В данной работе авторы проанализировали более 35тыщ вопросов на Stack Overflow за период с 2019 по 2023 год.

Ключевые выводы:
1) Значимость безопасности: Темы, связанные с безопасностью, занимают четвертое место по популярности среди всех обсуждений Kubernetes, составляя 12,3% от общего объема дискуссий.
2) Доминирующие проблемы: Три основные области — управление сертификатами TLS/SSL, управление секретами и управление идентификацией и доступом (IAM) — вызывают подавляющее большинство вопросов и интереса.
3) Разрыв между вопросами и интересом: В то время как количество новых вопросов по безопасности остается относительно стабильным, количество просмотров этих тем резко растет, что свидетельствует о массовом внедрении платформы и поиске уже существующих решений.
4) Проблемы конфигурации: Около 28% всех обсуждений касаются конфигурации кластеров, что подтверждает тезис о высокой сложности Kubernetes и риске возникновения уязвимостей из-за неправильных настроек.

Сегодня хотим поделиться с вами интересным докладом – Path Safety in the Trenches от Aleksa Sarai с прошедшей
Linux Plumbers Conference.

Автор доклада – один из главных мейнтейнеров runc. В докладе он разбирает первопричину возникновения уязвимостей подобных CVE-2025-31133. В своем выступлении он рассматривает многочисленные вопросы, необходимые для защиты программ пользовательского пространства от подобных атак, завершенная и текущая работа над ядром, направленная на упрощение решения этих проблем, а также опыт миграции кодовой базы среды выполнения контейнеров на архитектуру, которая делает акцент на path-safety.

Кроме того, в докладе будет представлена ​​обновленная информация о libpathrs (библиотеке, предназначенной для значительного упрощения противодействия этим атакам для большинства программ Linux).

Сегодня нашему каналу k8s (in)security исполняется 6 лет !!!

Мы всей нашей R&D командой Luntry стараемся держать уровень и радовать вас новыми интересными материалами и мыслями про безопасность контейнеров и Kubernetes!

Не так давно мы пересекли рубеж в 12 000 подписчиков и продолжаем уверенно расти благодаря вам и формировать отличное сообщество. Вместе с вами в этом году мы уже проведем 4 специализированную конференцию БеКон!

Будем рады если поздравите нас в комментариях и/или поделитесь ссылкой на наш канал с друзьями, что интересуются данной темой.

P.S. А для меня это всегда двойной праздник, так как День рождение и у моего сынишки, который на 1 год младше данного канала)

У Trivy опять большие проблемы. 19 марта 2026 года злоумышленники использовали похищенные учетные данные для публикации вредоносных версий Trivy, а также trivy-action и setup-trivy. Хотя поначалу эта активность казалась единичным случаем, на самом деле она стала результатом более масштабной многоэтапной атаки на цепочку поставок, начавшейся несколькими неделями ранее.

Атакующим удалось подменить почти все (75 из 76) версии Trivy. Вредоносный код выполнялся до сканирования и крал секреты: токены, SSH-ключи, креды от облачных провайдеров и другие чувствительные данные.

Если вы используете бинарь trivy, или trivy-action / setup-trivy в Github Actions – незамедлительно проверьте используемую версию.

Также Trivy выпустили Security Advisory со всеми деталями по этому инциденту.

16 февраля наша команда Luntry провела вебинар «Синергия безопасности Luntry и Штурвал. Часть 2» совместно с платформой управления средами контейнерной оркестрации «Штурвал».

В нем мы обсудили:
- Контроль Kubernetes кластеров;
- Безопасность образов контейнеров.

Если вы пропустили первую часть, то там были темы:
- Права доступа;
- Сетевая безопасность;
- Мультитенантность и контроля Kubernetes ресурсов.

Сейчас на нашем сайте доступны все материалы как первой, так и второй части!

P.S. Впереди еще часть 3 ;)

Команда SIG Security Kubernetes провела работу по обновлению OWASP Kubernetes Top 10, чтобы помочь операторам кластеров и пользователям сориентироваться в вопросах безопасности Kubernetes.

OWASP Top 10 Kubernetes 2025 показывает основные риски безопасности в современных кластерных средах. Среди них — небезопасные конфигурации workloads, чрезмерно широкие права доступа, ошибки в управлении секретами и отсутствие кластерных политик безопасности.

В список также входят отсутствие сетевой сегментации, излишне открытые компоненты Kubernetes, уязвимые настройки кластера, возможность lateral movement из кластера в облако, проблемы аутентификации и недостаточный уровень логирования и мониторинга.

Последнее обновление OWASP Kubernetes Top 10 было в 2022 году.

Для того чтобы быть на острие прогресса, технологий и развития своего решения наш R&D изучает не только что делают в OpenSource и в других коммерческих решения, но и что твориться в академической сфере.

Недавно к нам на глаза попалась работа "KubeFence: Security Hardening of the Kubernetes Attack Surface" от 2025 года.

Основная идея:
1) Инструмент анализирует Helm chart
2) Генерирует политики по принципу наименьших привилегий для ресурсов данного приложения (по сути whitelist)
3) Политики грузятся на Proxy перед Kubernetes API и блокируют, то что не подходит под политики

Наши мысли:
1) Непонятно почему авторы качественно сравнивают свой инструмент с RBAC ... Сравнивать механизм валидации с механизмом авторизации странная идея. И победа новой разработки очевидна.
2) Правильнее было бы сравнивать разработку с PolicyEngine (Kyverno, OPA Gatekeeper), которые также валидируют содержимае YAML ресурсов

Давайте сравним и посмотрим на различия `KubeFence` и PolicyEngine:
1) Создание политик: Первый создает автоматически, второй вручную
2) Принцип действия политик: Первый по сути это whitelist, а второй blacklist
3) Область действия политик: Первый для конкретного приложения, второй очень гибко (от конкретного приложения до всего кластера)
4) Механизм реализации: Первый через proxy, а второй через Admission Webhook

И в таком сравнении KubeFence уже выглядит не так убедительно.

К сожалению, исходный код проекта авторы так и не выложили.

Исследователи из Qualys раскрыли набор критических уязвимостей в модуле безопасности AppArmor для Linux, получивших общее название CrackArmor. Найдено девять уязвимостей, позволяющих непривилегированному локальному пользователю повысить привилегии до root. Проблема затрагивает миллионы систем и существует в ядре Linux как минимум с 2017 года.

Уязвимости основаны на классе ошибок «confused deputy»: атакующий может заставить доверенные привилегированные процессы выполнить действия от его имени. В результате возможно обходить политики безопасности AppArmor, получать полный root доступ или вызывать сбой системы.

Согласно биллютеням безопасности, эксплуатация этих уязвимостей теоретически может позволить осуществлять сценарии побега из контейнера, хотя на момент написания статьи это еще не было продемонстрировано на практике.

Исправления уже готовятся и распространяются через обновления ядра и связанных компонентов.

Отличный туториал "How Container Images Actually Work: Layers, Configs, Manifests, Indexes, and More" для того чтобы раз и навсегда разобраться что такое образы контейнеров и как они устроены.

В Kubernetes часто говорят о «безопасных настройках по умолчанию», но на практике они сильно зависят от конкретного дистрибутива. Один из примеров — MicroK8s, где RBAC по умолчанию отключён.

Это означает, что в базовой установке контроль доступа между пользователями и сервисами фактически отсутствует, что может стать неприятным сюрпризом для тех, кто привык к более строгим дефолтам в других сборках Kubernetes.

В статье "Variance of defaults - Microk8s RBAC "разбирается, почему так получилось, какие риски это создаёт и почему при работе с MicroK8s стоит сразу проверять и включать RBAC вручную.

Ребята из проекта Minimus (делают OCI container base hardened images) выпустили статью "Fast Go CVE Remediation: Reducing CVE Risk With Hardened Container Images", в которой рассказывают как у них устроен внутренних процесс поддерживания выпускаемых образов в максимально обновленном безопасном состоянии для проектов на Go.

В основе лежит 2 фактора:
1) Минималистичность образа
2) Низкий Mean Time To Remediate (MTTR) для уязвимостей

Вот второму аспекту и посвящена данная блоговая запись. Тут есть 3 основных составляющий:
1) Быстрое обнаружение
2) Сборка образов из исходников
3) Автоматизация исправления

При этом в зависимости от типа уязвимости в Go их сценарии по исправлению отличаются:
- Уязвимость в самом проекте
- Уязвимость в зависимости
- Уязвимость в Go toolchain

В общем, полезно всем кто заботиться о приготовлении у себя безопасных образов.

25 марта 2026 в 11.00 наша команда Luntry поделится опытом и экспертизой в рамках вебинара "Безопасность AI, ML и Big Data кластеров"!

очень много говориться о безопасности AI агентов, кода, нейронок, алгоритмов и т.д. Но незаслуженно мало вниманию уделяется внимая окружению где это все создается и/или живет. Поговорим о влиянии Big Data на безопасность в Kubernetes.

В процессе этого вебинара мы раскроем следующие моменты:
- Специфика кластеров, где работают с AI;
- Разбор всех 7 доменов безопасности на кластерах с Big Data;
- Что можно и нельзя делать в кластерах с ML;
- Как Luntry помогает решить задачи, связанные с безопасностью образов.

Зарегистрироваться можно тут.

В ingress-nginx обнаружена (очередная) критическая уязвимость CVE-2026-3288, связанная с обработкой аннотаций Ingress ресурсов. Некоторые значения аннотаций подставляются в шаблон конфигурации NGINX без достаточной фильтрации, что позволяет атакующему внедрить произвольные директивы в итоговый nginx.conf. Уязвимость затрагивает версии ingress-nginx до 1.13.7 / 1.14.3.

Атака возможна, например, через аннотацию nginx.ingress.kubernetes.io/rewrite-target. Специально сформированное значение может привести к конфигурационной инъекции: при генерации конфигурации контроллер вставляет его в NGINX шаблон, после чего в nginx.conf появляются дополнительные директивы (например include, lua и другие). Это позволяет выполнить код в контексте ingress-nginx controller.

Эксплуатация дает возможность получить доступ к секретам и другим ресурсам Kubernetes, к которым имеет доступ контроллер, а в ряде сценариев — привести к полной компрометации кластера.

С каждым днем все острее встает вопрос запуска не доверенного кода в виде AI Agents и то что они создают. И сегодняшний проект "The Agent Sandbox Taxonomy (AST)" как раз призван помочь понять и разобраться на что стоит обращать внимание и какие вообще есть варианты реализации. Также автор приводит результаты сравнения для 23-х проектов: от Docker Sandbox до Claude code, Cursor и replit.

Среди окружений запуска отдельно автор выделил Kubernetes (без него сегодня уже никуда).

Среди механизмов безопасности естественно встречаются: MicroVM, Policy engine.

P.S. Скоро и мы поделимся нашим опытом защиты AI кластеров Kubernetes ;)

13 марта в 11:00 состоится онлайн-конференция AM Live “Безопасность контейнерных сред: что реально работает в 2026”. Наша команда Luntry, примет участие и вместе с другими спикерами обсудит реалии 2026 в области защиты контейнеров.

Зарегистрироваться можно тут.

В Kata Containers раскрыта критическая уязвимость CVE-2026-24834, позволяющая пользователю контейнера получить выполнение произвольного кода с правами root внутри guest microVM. Проблема возникает из-за взаимодействия runtime с Cloud Hypervisor, где контейнер может модифицировать файловую систему, используемую гостевой VM. Для эксплуатации уязвимости необходима capability CAP_MKNOD.

Таким образом, злоумышленник из контейнера способен повысить привилегии внутри виртуальной машины и фактически полностью контролировать guest окружение. При этом на текущий момент считается, что уязвимость не позволяет выйти на хост или повлиять на другие контейнеры и VM на том же сервере.

Уязвимость имеет оценку 8.8 по CVSS v3 и затрагивает версии Kata Containers ниже 3.27.0; исправление уже выпущено в релизе 3.27.0.

"Upgrade AWS CSI Drivers in your Multi-Tenant Kubernetes Cluster" - интересная короткая история из 2025, которая рассказывает как DaemonSet с неочевидными правами в ServiceAccount способен свести на нет multi-tenancy на базе node isolation. В общем, хороший урок о важности анализировать права в RBAC.

Компрометациия репозитория Trivy произошла в рамках крупной автоматизированной кампании атак на CI/CD пайплайны GitHub Actions. Автономный бот под именем hackerbot-claw, описываемый как агент на базе Claude Opus 4.5, сканировал публичные репозитории на предмет уязвимых workflow и использовал различные техники, чтобы добиться выполнения произвольного кода и похитить токены с правами записи. В результате он получил доступ к Trivy через ошибочно настроенный pull_request_target workflow и ворованным токеном инициировал удаление релизов и другие изменения.

Атака затронула несколько популярных проектов. В кампании были задействованы репозитории Microsoft, DataDog, CNCF проект akri, awesome-go с 140 000+ звезд и другие. В ряде случаев бот добивался удалённого выполнения кода и кражи GITHUB_TOKEN. hackerbot-claw открывал десятки PR, иногда внедрял полезную нагрузку через имена веток или модификации файлов, и вёл собственный лог активности.

Команда Aqua Security уже устранила уязвимость и восстановила Trivy. Уязвимый workflow был удалён, скомпрометированные токены отозваны, вредоносный артефакт VSCode расширения удалён, а новая версия Trivy (v0.69.2) опубликована.