Вышла новая версия Kyverno 1.17!

0) Сильно обновили и прокачали библиотеку политик - более 600!
1) Добавлены неймспейсные политики для мутации и генерации (NamespacedMutatingPolicy, NamespacedGeneratingPolicy) - ранее были только кластерные
2) Новые CEL политики достигли версии v1 (GA). Благодаря этому переходу команды разработчиков платформы могут уверенно перейти от политик на основе JMESPath к CEL, чтобы воспользоваться преимуществами значительно улучшенной производительности и лучшей согласованности с вышестоящими нативными политиками Kubernetes в виде ValidatingAdmissionPolicies/MutatingAdmissionPolicies.
3) Добавили новые CEL возможности и функции
4) Уход от legacy API. Policy и ClusterPolicy больше развиваться не будут, тоесть в новых версия нужно успеть сделать миграцию на CEL политики!

Capacitor — это UI для FluxCD. Инструмент подключается к кластеру через kubeconfig и дает удобный обзор приложений, Helm релизов и всех связанных ресурсов в одном месте.

Поддерживает мультикластерность, RBAC и сравнение желаемого и фактического состояния ресурсов. Можно быстро понять, что именно задеплоено, где есть дрейф и какие изменения пришли из Git.

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

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

Мы рады сообщить, что мы запустили старт продаж билетов на нашу конференцию по безопасности контейнеры и Kubernetes - БеКон 2026!

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


Билеты можно купить тут!

Наверно одним из самых странных или неправильных на мой взгляд (в моем топе) запросов за время консультирования по вопросам безопасности и построения систем защиты в 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

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

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