В 117 приказе ФСТЭК появилась мера по защите технологий контейнерных сред и их оркестрации!

А если обратиться к его методическому документу, то там есть раздел "4.5. Защита технологий контейнерных сред и их оркестрации (ЗКО)" и в нем есть 8 пунктов:

ЗКС.1 Контроль целостности в контейнерных средах
ЗКС.2 Регистрация событий безопасности в контейнерных средах
ЗКС.3 Управление доступом в контейнерных средах
ЗКС.4 Резервное копирование в контейнерных средах
ЗКС.5 Изоляция контейнеров в контейнерной среде
ЗКС.6 Идентификация и аутентификация в контейнерной среде
ЗКС.7 Управление контейнерами и их образами (оркестрация)
ЗКС.8 Выявление уязвимостей в контейнерной среде

Российская регуляторика продолжает развиваться в направлении контейнеров и это не может не радовать!

Agent Sandbox — это проект от Kubernetes SIG Apps, который решает новую задачу: запуск изолированных и stateful AI агентов прямо в Kubernetes. Он вводит специальный CRD Sandbox, позволяющий описывать «одиночные» долгоживущие окружения с постоянным хранилищем и стабильной сетевой идентичностью.

Ключевая идея — дать Kubernetes нативный способ управлять workload’ами, которые не вписываются в Deployment или StatefulSet: например, агентами, dev средами или ноутбуками. Sandbox ведёт себя как легковесная VM на базе контейнера, с lifecycle операциями вроде pause/resume и возможностью безопасно исполнять недоверенный код.

Проект особенно интересен в контексте AI: он стандартизирует инфраструктуру для agent based систем, добавляя изоляцию через gVisor/Kata, шаблоны, pre warmed окружения и API.

ingress-nginx контроллер продолжает радовать пентесеров и с ними связанных специалистов ...

CVE-2026-4342 — уязвимость высокой степени критичности (CVSS 8.8) в ingress-nginx контроллере, позволяющая внедрять произвольную конфигурацию с помощью специально созданных аннотаций Ingress. Это позволяет злоумышленникам осуществлять удаленное выполнение кода (RCE) и красть секреты в кластере.

Уязвимые версии: < v1.13.9, < v1.14.5 и < v1.15.1.

Подозрительные данные в поле rules.http.paths.path ресурса Ingress могут указывать на попытку использования этой уязвимости.

Еще используете ingress-nginx ?

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

Большое всем спасибо кто прислал свои заявки к нам в CFP БеКон!
В ближайшую неделю мы все про анализируем и ко всем вернемся с ответом.
Так что полный список докладов будет уже совсем скоро.

P.S. А если вы еще сомневаетесь стоит ли идти/приезжать на БеКон, то в этом году будет опять секретный доклад как в том году ;)

Container escape — это не «экзотика», а базовый сценарий – атакующий исполняет код внутри контейнера и дальше ищет путь к хосту через ядро, runtime или мисконфигурацию. Вся проблема в том, что контейнеры делят одно ядро, поэтому успешный escape = компрометация всей ноды и потенциально кластера.

Статья Container Escape Telemetry: Series Overview (вернее сборник статей) делает акцент на телеметрии: одиночные сигналы бесполезны, важно собирать цепочки событий (syscalls, доступ к /proc, работа с runtime сокетами) и коррелировать их. Типичные индикаторы — mount/setns, доступ к docker.sock, попытки эскалации черерз capability и нетипичное поведение процессов внутри контейнера.

Главный takeaway — большинство escape’ов происходит не из-за 0day, а из-за мисконфигов (privileged, лишние capabilities, hostPath). Поэтому detection должен быть поведенческим и контекстным (а лучше – гибридным), а защита — банально про least privilege и контроль рантайма, иначе любой foothold в контейнере быстро превращается в полный захват инфраструктуры.

На нашем сайте Luntry в разделе исследований стали доступны материалы с выступления «Путеводитель по безопасности контейнеров и Kubernetes» (видео, слайды) с онлайн-митап CyberCamp 2026 по теме DevSecOps.

Данный материал расставляет ориентиры с чего стоит начать при погружении в данную тему. При этом предлагает как теорию, так и практику.

Вопросы можно задавать в комментариях к данному посту!

Экосистема микро-виртуальных машин прошла испытание временем задолго до того, как появился спрос на агентный ИИ. Сегодня она процветает, отличается разнообразием и быстро развивается.

В статье Your Container Is Not a Sandbox рассматриваются все VMM, shared Rust crate ecosystem, десяток платформ для тестирования ИИ, а также объективные компромиссы.

Seccomp — это механизм ядра Linux, который ограничивает системные вызовы процесса и тем самым снижает поверхность атаки, но на практике его использование в контейнерах часто даёт ложное чувство безопасности. В статье "Seccomp, Seccomp, and Syscalls: BSidesSF and Seccomp in Kubernetes" разбирается, что реальные применённые профили seccomp могут отличаться от ожидаемых из-за различий в версиях ядра, runtime и конфигурации, и это сложно заметить заранее.

Главная мысль — смотреть не на JSON профили, а на фактическое поведение процесса: какие syscalls реально разрешены в рантайме. Для этого автор показывает подход и инструменты, которые извлекают seccomp BPF прямо из процесса и позволяют сравнивать профили между контейнерами. Это даёт «ground truth» и помогает находить неожиданные разрешённые вызовы, включая потенциально опасные (например, связанные с io_uring).

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

В продолжение вчерашнего поста о Seccomp, рассмотрим цикл статей от того же автора (Mark Manning). Cтатья "Seccomp in K8s 1/3: Building Insecure and Incomplete Profiles" показывает, что проблема глубже, чем просто расхождение между ожиданиями и реальностью. Даже если вы генерируете собственные профили, они часто оказываются либо слишком широкими, либо неполными, что сводит пользу к минимуму.

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

Seccomp нельзя эффективно использовать “в лоб”. Без системного анализа, сравнения с дефолтными профилями и проверки качества политики он может даже ухудшить безопасность.

Не так давно прошла конференция KubeCon + CloudNativeCon Europe 2026 в Амстердаме. А сейчас стали доступны видеозаписи с нее. Мы со своей стороны выделим те что затрагивают тему информационной безопасности:
- "Audit-ready Kubernetes: How Chase UK leveraged policy-as-code for continuous compliance"
- "SBOOM: Making SBOMs Play Together
- "Zero-CVE Containers"
- "Kubernetes security at Shopify scale: Automating security across an infrastructure monrepo"
- "What LLMs do, and don't, know about securing Kubernetes"
- "Least-Privilege for AI: Authorizing Agents and MCP Tools"
- "Elevating EKS Security: Admin and Advanced Network Policies for Multi-Layer Protection"
- "How VPC Lattice simplifies secure multi-cluster networking on EKS"
- "Why Isn't the Fix in My Container? Tracking CVE Propagation Across 10,000 Projects"
- "When Multitenancy Goes Wrong: A Deep Dive Into Kcp’s First CVE"

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

Мы уже отобрали все доклады для нашей конференции по безопасности контейнеров и Kubernetes - БеКон 2026! Уже совсем скоро мы опубликуем подробную информацию на сайте. Но уже сейчас в виде тем мы можем сказать что будет представлено на конференции:
- Mandatory Access Control (MAC),
- Supply-chain Levels for Software Artifacts (SLSA),
- Attacks,
- Malware,
- Container specific OS,
- Validating Admission Policies (VAP),
- Network Policy,
- Integrity Control,
- Hardened Java Images,
- Policy Engines,
- Построение процессов,
- Сертификация ФСТЭК.

И все это связано с контейнерами и Kubernetes!
Ни одного шага ни влево, ни вправо)

Продолжаем рассказывать о Seccomp в контексте цикла статей от Mark Manning.

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

Приводятся примеры, где разрешённые вызовы комбинируются таким образом, что позволяют обойти ограничения или добиться нежелательного поведения. Кроме того, важную роль играют особенности ядра и различия в реализации, из-за которых один и тот же профиль может вести себя по-разному.

Seccomp остаётся полезным механизмом, но без учёта возможных bypass техник его нельзя считать надёжной защитой.

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

Для этого они через модуль в CanisterWorm, названного "host-provisioner-iran", который был разработан для специальной целевой деструкции инфраструктуры Kubernetes в системах, определённых как иранские на основе часовых поясов и локализации. Согласно исследованиям Charlie Eriksen из Aikido, если вредонос обнаруживал, что жертва находится в Иране и имеет доступ к кластеру Kubernetes, он развёртывал привилегированный DaemonSet с определенными настройками для гарантии планирования и запуска на каждом узле в кластере, после чего стирал все данные на каждом узле. Если он не обнаруживал Иран, он молча выходил, оставляя постоянный бэкдор полностью функциональным для будущего использования.

Заключительная статья "Seccomp in K8s 3/3: Measuring, Scoring, and Scaling with Seccompute" о Seccomp в контексте цикла статей от Mark Manning.

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

В статье предлагается подход к измерению качества профилей: анализ покрытия syscalls, оценка избыточности и попытки формализовать «полезность» политики. На этом фоне появляется инструмент Seccompute, который помогает автоматически сравнивать и оценивать профили.

Ключевая идея — переход от ручного «тюнинга» к системному процессу с метриками, скорингом и возможностью масштабирования на уровне кластера.

21 марта 2026 года в Амстердаме прошла конференция Cloud Native Rejekts EU 2026 (запись 1 зала, 2 зала) и естественно были доклады и по информационной безопасности, касающиеся контейнеров и Kubernetes. Мы для вас выделили наиболее интересные:
- "Hardening Kubernetes: Our Journey to FIPS Compliance" - практические аспекты внедрения строгих криптографических стандартов в Kubernetes-инфраструктуре.
- "Type 1 Fun with Type 1 Hypervisors: The Comeback of Hardware-Backed Isolation" - архитектура с аппаратно-поддерживаемой виртуализацией как к способу обеспечения более строгой изоляции в облачных окружениях
- "Achieving Platform Engineering Multi-Tenancy with kcp and Crossplane" - архитектурные подходы к обеспечению безопасной многопользовательской среды в Kubernetes
- "Unleashing the Tides of Kubernetes Networking by Removing kube-proxy" - как удаление kube-proxy может улучшить производительность и безопасность Kubernetes сети
- "Sherlock Pods: Investigating a Compromised Kubernetes Cluster" - про форензику скомпрометированного кластера
- "Push the boundaries of kubernetes multi tenancy with container runtimeclasses" - как и что работает при использование RuntimeClasses

P.S. А мы уже во всю готовим анонс докладов с предстоящего БеКон 2026!

k8scout — это экспериментальный open source инструмент для offensive security в Kubernetes, который строит граф атак и помогает понять возможные пути эскалации после первоначального доступа.

Проект фокусируется именно на пост-эксплуатации: анализирует права, роли и связи (pod → service account → role → доступ), а также ищет потенциальные векторы lateral movement вроде impersonation или доступа к секретам. Это позволяет быстро ответить на ключевые вопросы атакующего — какие есть привилегии и куда можно двигаться дальше внутри кластера.

RootlessKit — инструмент, который позволяет запускать контейнеры без прав суперпользователя (root). Он создает изоляцию и видимость "мнимого root" (fakeroot), защищая основную операционную систему хоста от потенциальных угроз и атак через контейнеры.

Основные функции:
- Пространства имен (Namespaces): Создает изолированные пространства имен пользователей (user_namespaces) и точек монтирования (mount_namespaces).
- Мапинг UID/GID: Вызывает системные утилиты newuidmap и newgidmap для распределения диапазонов подчиненных идентификаторов (subuid/subgid) пользователя в пространстве контейнера.
- Сетевая изоляция: Поддерживает создание изолированных сетевых пространств (network_namespaces) с трансляцией сетевых адресов (NAT) на уровне пользователя, используя такие драйверы, как slirp4netnsили gvisor-tap-vsock.

Проект активно применяется в качестве базового компонента для изоляции в популярных экосистемах контейнеризации:
- Docker / Moby — при запуске демона в официальном режиме Rootless.
- Podman — начиная с версии 1.8.0.
- BuildKit — инструмент сборки образов нового поколения.
- K3s и Usernetes — легковесные дистрибутивы Kubernetes.
- nerdctl — Docker-совместимый интерфейс командной строки для containerd.

Unpatchable Vulnerabilities of Kubernetes: CVE-2020-8562 – очередная статья про unpatchable CVE в Kubernetes. Речь о баге в API server proxy, который позволяет обойти защитные фильтры и обращаться к внутренним сервисам кластера через SSRF подобную атаку.

Kubernetes дважды резолвит DNS (для проверки и для запроса), и атакующий может подменить ответ между этими шагами. Это дает возможность обходить ограничения и получать доступ к чувствительным ресурсам вроде localhost или metadata сервисов через DNS rebinding.

Эксплуатация требует повышенных прав (например, создание Node и доступ к proxy). Полностью устранить проблему нельзя — только снизить риски (например, через минимальный TTL DNS или Konnectivity).

Недавно наткнулись на интересный доклад "Lateral Movements in Kubernetes" от исследователя из Microsoft c RSA Conference 2023.

Доклад будет полезен как пентестерам, так и специалистам SOC, да и вообще всем кто защищает кластера Kubernetes.

Речь в докладе заходит и про Threat Matrix for Kubernetes от Microsoft.

Вышел Kubernetes 1.36 под кодовым названием Haru. И как обычно, мы рассказываем про улучшения и обновления с точки зрения security.

Главное «ломающее» изменение — постепенный отказ от externalIPs, так как механизм позволял перехватывать трафик и создавать MITM-атаки. Также усиливается валидация IP/CIDR и обновляется работа с сертификатами, что снижает риск некорректных конфигураций.

Среди новых security фич — constrained impersonation (ограничение прав при impersonation) и flagz endpoint для аудита параметров запуска компонентов. Они делают контроль доступа и проверку конфигурации кластера более прозрачными и безопасными по умолчанию.

Дополнительно в stable выходят user namespaces и более гранулярная авторизация Kubelet API, что помогает соблюдать принцип наименьших привилегий.