В 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 году.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сегодня в центре нашего внимания исследование «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 и риске возникновения уязвимостей из-за неправильных настроек.