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

В 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.

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

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

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

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

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

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

В 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, к которым имеет доступ контроллер, а в ряде сценариев — привести к полной компрометации кластера.

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

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

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

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

Ребята из проекта 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

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

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

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

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

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

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

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

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

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

Для того чтобы быть на острие прогресса, технологий и развития своего решения наш 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 уже выглядит не так убедительно.

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

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

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

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

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