Наверно одним из самых странных или неправильных на мой взгляд (в моем топе) запросов за время консультирования по вопросам безопасности и построения систем защиты в Kubernetes был: "Нам нужно чтобы у ИТ не было возможности это видеть/понимать/контролировать/участвовать/... в процессе обеспечения безопасности в Kubernetes". Кому-то тут может быть смешно, но такое доводилось слышать не 1 раз...

При этом вспоминаем, что DevSecOps это процесс и коммуникация между разными департаментами. Также открываем CNCF Cloud Native Security Whitepaper и читаем, там что обеспечении безопасности в Cloud Native это кросс командная вещь и в ней участвуют и разработчики, и оперейшен команду, и команды безопасности.

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

А вы встречались с таким запросом/ситуацией?

Из статьи «Google Cloud Shell Container Escape» можно узнать, как исследователь разобрал архитектуру Google Cloud Shell и показал, что среда работает внутри привилегированного контейнера, а не изолированной VM. Ценность материала — в детальном реверсе окружения и пошаговой эксплуатации через механизмы ядра вроде core_pattern и hotplug.

Автору удалось добиться container escape и получить root доступ на хосте Kubernetes ноды, что фактически ломает модель изоляции Cloud Shell. При этом он всё же остался внутри инфраструктуры Google Compute Engine, то есть речь не о компрометации всей платформы, а о выходе из пользовательского контейнера.

Основной вывод: если контейнер запущен с избыточными привилегиями и доступом к чувствительным возможностям ядра, его границы становятся условными. В итоге мы работаем в «полуизолированной» среде и не можем полностью доверять её модели безопасности.

Guardon — это расширение для Chrome, которое проверяет YAML файлы K8s на соответствие политикам и при этом не требует настройки инфраструктуры или изменений в ваших пайплайнах.

Вы просто устанавливаете его и открываете любой YAML-файл в веб-интерфейсе GitHub или GitLab. Проверка запускается в один клик.

Guardon меняет правила игры, перенося безопасность прямо в браузер (Весь анализ происходит локально в вашем браузере - никакой утечки информации). Это Shift Left в чистом виде: вы ловите ошибки в тот момент, когда смотрите код, сокращая время выхода продукта на рынок за счет мгновенного фидбека.

Найти ошибку — это только 50% дела. Guardon экономит время, предлагая функцию Smart fix suggestions. Патчи в двух видах Preview patch и Copy snippet.

При этом под капотом у инструмента всем хорошо знакомые движки: Open Policy Agent (OPA) (rego правила) и Kyverno политики. Политики от Kyverno он еще позволяет легко импортировать!

Cilium 1.19 вышел с рядом заметных улучшений сетевого стека и безопасности, отмечая 10-летие проекта с почти 3 000 коммитов от более 1 000 контрибуторов. Основные новшества касаются прозрачного шифрования трафика: теперь можно включать Ztunnel в бета-режиме, чтобы обеспечить автоматическое шифрование и аутентификацию TCP-соединений между рабочими нагрузками без прокси сайдкаров. Также добавлены строгие режимы для IPsec и WireGuard, которые требуют, чтобы весь трафик между узлами был зашифрован.

Сетевые политики стали более выразительными и удобными в отладке, появились расширенные DNS паттерны и более безопасные значения по умолчанию для многоузловых кластеров. Multi Pool IPAM переведён в стабильный статус и теперь работает с IPsec и прямой маршрутизацией, что полезно для распределённых и сегментированных адресных пространств.

Наблюдаемость через Hubble улучшена: можно трассировать пакеты с учётом параметров шифрования и получать информацию о том, какая политика вызвала отбрасывание трафика. Всё это делает Cilium 1.19 интересным обновлением для крупных Kubernetes инсталяций с высокими требованиями к безопасности и сложным сетевым окружением.

Напоминаем, что идет прием заявок на доклады БеКон 2026 и до его закрытия осталось чуть меньше месяца! Единственная конференция по безопасности контейнерных технологий ждет ваших заявок ;)

Есть 2 трека со строгим логическим разделением.

1 трек - Ингредиенты

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

2 трек - Рецепты

Данный трек посвящен людям, командам и процессам связанным с безопасностью контейнеров и Kubernetes. Он для С-level, Leads, которые продумывают и выстраивают все в компании.

Также есть возможность ЗАКАЗАТЬ доклад ;)

P.S. Как всегда будем рады обсудить и помочь сформировать заявку если у вас есть мысль/идея, но вы не уверены в ней.

P.S.S. Будем признательны за репост!

Компрометациия репозитория 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) опубликована.

"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

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