Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Сегодня хотим познакомить вас с одним необычным проектом с идеей о которой я думаю так или иначе задумывались многие ;)
Проект Kine это etcdshim
, который транслирует etcd API
к:
- SQLite
- Postgres
- MySQL/MariaDB
- NATS
Тут же вспоминается недавняя статья "65,000 nodes and counting: Google Kubernetes Engine is ready for trillion-parameter AI models" в которой рассказывалось, что для достижения таких умопомрачительных показателей (одним из изменений) было решено отказаться от etcd
в пользу Spanner
.
Давайте в комментариях накидаем мнений ЗА и ПРОТИВ подобной идеи.
P.S. Наверное предновогоднее настроение сказывается и тянет на что-то необычное, странное, сказочное наподобие такого)
Сегодня хотим отдельно рассказать про доклад, который мы вскользь упоминали в начале года – "I'll Let Myself In: Kubernetes Privilege Escalation Tactics" от Iain Smart & Andrew Martin
. Авторы, уже рассказывали его на нескольких конференциях, последний раз на Kubernetes Community Days UK
.
В докладе авторы делятся способами повышения привилегий в Kubernetes
кластерах, что будет полезным если вы делаете пентесты. Также не забывают и про постэксплуатацию.
На примере разбирается демо с Argo CD
и побегом из контейнера в CI/CD
.
Наверняка если вам нужно изучить структуру какого-нибудь ресурса из Kubernetes
вы идете в документацию и смотрите API Overview.
Но это не всегда бывает удобно, поэтому сегодня хотим порекомендовать вам ресурс kubespec.dev. По сути это тоже своего рода структурированная документация по структурам ямлов всех Kubernetes
ресурсов, но в более удобном и красивом отображении.
Из плюсов можно добавить возможность сравнения ресурсов между собой по версиям, примеры манифестов, а также поддержку кастомных ресурсов, например Kyverno
, Cilium
, Istio
и т.д.
Проект появился недавно и активно развивается, так что в скором времени можно увидеть и другие фичи.
На просторах сети интернет есть такая серия постов как "Hands-on lab: Full Kubernetes compromise, what will your SOC do about it?". Состоит она из 4
частей:
1) Введение - легенда про вымышленную компанию Kuby
, в которой случился инцидент и были слиты их данные. Дается описание инфраструктуры компании.
2) Построение уязвимой инфраструктуры Kuby - стек Terraform
, Amazon EKS
, GitHub Actions CI/CD pipeline
.
3) Атака инфраструктуры Kuby - supply-chain attack
приводящий к backdoor
.
4) Расследование инцидента - анализ событий в GuardDuty
и сбор релевантных артефактов и что можно еще улучшить.
Это будет полезно и offensive
и defensive
, а также DevOps
.
P.S. Один из наших партнеров в этом году сделал чумовую лабу под Luntry, на решение сценариев которой ушло 3-4 дня! Это было настолько здорово, что мы договорились ее развивать совместно.
Непонятно как так получилось, но более чем за 4-х
летнюю историю нашего канала, мы ни разу не писали про OWASP Kubernetes Security Cheat Sheet.
За это время мы писали про:
- OWASP Microservices based Security Arch Doc Cheat Sheet
- OWASP Kubernetes Top 10 (критиковали это творение, которое так с 2022
года ни разу и не обновлялось)
- OWASP Top 10 CI/CD Security Risks (даже это попало на наши радары)
Но не про OWASP Kubernetes Security Cheat Sheet
... А он в действительности очень хорош и активно обновляется! И вот недавно по просьбе клиента мы рассказывали как Luntry позволяет это все помочь решить, мы поняли что на канале об этом ни разу не писали. Сегодня - исправляемся)
P.S. В январе в рамках нашего вебинара/стрима мы рассмотрим этот Cheat Sheet
и смапим его полностью на возможности Luntry
;)
Сегодня хотим поделиться большим и классным по наполнению воркшопом от Ian Smart
и Rory McCune
"Container Security Workshop
", представленным на прошедшей недавно конференции BSides London 2024
.
В воркшопе рассмотрели все возможные аспекты безопасности Docker
и Kubernetes
. Слайды можно посмотреть тут.
Официально вышла новая версия Kubernetes 1.32
с кодовым именем "Penelope"
. Данная версия содержит 44 улучшения, из которых 13
ушли в Stable
, 12
в Beta
и 19
в Alpha
.
Мы уже писали о ряде security
улучшений данной версии, но можно ознакомиться и с другими обзорами [1,2,3].
KubeLab - offline
платформа для изучения Kubernetes
. На ее базе можно выполнять и создавать практические лабораторные работы. Проект находится в ранней стадии, но определенно многим будет полезен для изучения.
В качестве online
платформы IMHO
безусловным лидером является iximiuz Labs!
Релиз Kubernetes 1.32
уже не за горами (на этой неделе), все изменения внесены, а это значит что можно посмотреть, что нового, с точки зрения security
, нас ждёт в версии 1.32
.
Наверное, одно из самых заметных изменений это добавление Feature Gate KubeletFineGrainedAuthz, благодаря которому доступ до эндпоинтов /health
и получению списка Pods
на конкретной Nodes
будет разрешен соответствующими правами RBAC
nodes/healthz
и nodes/pods
.
Также внесли ряд улучшений в Kubernetes Audit Policy
, а вернее в логи, которые отставляет после себя этот механизм.
Нельзя не отметить изменения в Authentication
и Token Management
– добавлен JTI claim
, и другая дополнительная информация к Service Account Token
, AnonymousAuthConfigurableEndpoints
перешел в beta
и теперь включен по умолчанию.
В следующих постах обязательно рассмотрим эти улучшения по подробнее.
Разрабатывая решение для безопасности контейнеров, приходится отслеживать и изучать большое количество различных спецификаций, интерфейсов, сторонних решений, чтобы поддерживать большое количество разнородных окружений клиентов. Всем этим разработка очень усложняется и приходится тестировать все на очень большом количестве разных вариаций окружений.
Если вы, на пример, думали что спецификация образа контейнера зафиксирована и не изменяется, то вы ошибаетесь. Вот тут в changelog для Open Container Initiative Runtime Specification
можно посмотреть как они тихо, без громких анонсов уже доросли с версии 1.0
до 1.2
.
P.S. Напоминаем, что завтра в 11:00 наша команда Luntry проведет вебинар/стрим/эфир «Подпись и валидация образов в Kubernetes».
Недавно копаясь и разбираясь с различными container runtimes
, данное действие привело к проекту на Go
под названием runj.
runj - это экспериментальный OCI
-совместимый runtime
для FreeBSD jails
! Лично для меня это можно сказать завершение определённого цикла. Ведь механизм FreeBSD jails
появился в 2000
году, а это за 13
лет до появления Docker
, 15
лет до Kubernetes
и 17
лет до OCI
спецификация v1.0.0
для образов контейнеров. И тут можно сказать, что один из прародителей концепции контейнеров встретился со своим потомком =)
Если вам мало CRI
,CNI
,CSI
,CDI
,CMI
,CPI
, то встречайте еще один интерфейс в Kubernetes
под названием NRI
.
NRI - это Node Resource Interface
. По сути это механизм плагинов, позволяющий расширять возможности containerd
с 1.7
и CRI-O
c 1.26
. Можно добавить собственную логику, которая будет выполняться в такие моменты жизни Pods
как run
, stop
, remove
и контейнеров как creation
, post-creation
, starting
, post-start
, updating
, post-update
, stopping
, removal
.
В первую очередь это было создано для более низкоуровневой, эффективной работы с ресурсами и устройствами, на пример, которых нельзя описать просто OCI
спецификацией. Это может быть очень полезно облачным провайдерам или тем кто контролирует все свое железо и хочет заточится по его специфику. Примеры можно посмотреть тут и тут.
Также отдельно отметим очень высокий уровень критичности данного компонента, который по сути разливается привилегированным daemonset
- при написании подобного помните о безопасности.
P.S. В процессе изучения данной темы был найден интересный показательный проект Koordinator (QoS-based scheduling
), на котором можно проследить эволюцию подходов к управлению ресурсами в K8s
.
Сегодня хочется познакомить вас с одним достаточно не тривиальным проектом, который вы врятли запустите в проде сейчас, но по крайней мере заставит задуматься о возможностях контейнеризации, а для кого-то будет стартовой точкой написания своего инструмента или курсовой/диплома/...
Проект zeropod позволяет скалировать Pod
в 0
. Zeropod
— это Kubernetes runtime
(точнее, containerd shim
), который автоматически сохраняет контейнеры на диске после определенного времени последнего TCP
-подключения. В таком состоянии (scales down to zero
) он будет прослушивать тот же порт, который прослушивало приложение внутри контейнера, и восстановит этот контейнер при первом входящем подключении. В зависимости от размера программы с контрольной точкой это происходит за десятки или несколько сотен миллисекунд, практически незаметно для пользователя. Поскольку все содержимое памяти сохраняется на диске во время создания контрольной точки, восстанавливается все состояние приложения.
Для работы понадобиться установить данный runtime
на Nodes
, указать для соответствующих приложений runtimeClassName: zeropod
, а затем уже проект CRIU (уже неоднократно о нем писали на канале 1,2,3,4,5), который находится под капотом сделает свое дело. На схеме можно увидеть процесс активации контейнера после того как он был checkpointed
и к нему снова пошли сетевые обращения.
Опубликовали очередную багу в Cilium
– CVE-2024-52529. И в очередной раз бага связана с тем, что CiliumNetworkPolicy
не работают так как должны (тут мы рассказывали про подобный баг).
Проблема возникает когда есть L3
политика с выставленным port range
и L7
политика с портом из диапазона первой политики. В таком случае L7 CiliumNetworkPolicy
работать не будет. Например:
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "l3-port-range-rule"
spec:
endpointSelector:
matchLabels:
app: service
ingress:
- fromCIDR:
- 192.168.60.0/24
toPorts:
- ports:
- port: "80"
endPort: 444
protocol: TCP
apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
name: "l7-port-range-rule"
spec:
endpointSelector:
matchLabels:
app: service
ingress:
toPorts:
- ports:
- port: "80"
protocol: TCP
rules:
http:
- method: "GET"
path: "/public"
HTTP path
, а не только GET
-запросы к пути /public
, как это предусмотрено политикой l7-port-range-rule
.
Читать полностью…
10 декабря в 11:00 наша команда Luntry проведет вебинар/стрим/эфир «Подпись и валидация образов в Kubernetes». Там мы планируем рассмотреть следующие темы:
– подготовка инфраструктуры для подписи и валидации образов;
– написание pipeline
сборки для данного процесса;
– встраивание cosign
в pipeline
сборки;
– использование политик Kyverno
и OPA Gatekeeper
для валидации образов;
– возможности Luntry
для контроля данного аспекта в инфраструктуре.
Зарегистрироваться на вебинар можно по ссылке.
P.S. Так как это у нас полный live, то тут в комментариях можно написать ваши пожелания/вопросы, которые вы бы хотели увидеть в рамках данного эфира, чтобы мы максимально широко раскрыли данную тему.
Чтобы вам на новогодних праздниках было не скучно - мы залили к нам на сайт видео двух наших выступлений:
1) "Латаем огрехи в образах приложений до рантайма, во время и после" c DevOops 2024
2) "Готовим контейнеры полезно и вкусно" c SafeCode 2024
Теперь в нашем разделе Исследований есть абсолютно все что мы презентовали в этом году! А это более 15
технических докладов и воркшопов за 2024
год по теме безопасности контейнеров и Kubernetes
!
Хорошая статья "Evolution of pod’s privilege in EKS", демонстрирующая эволюцию механизмов предоставления прав Pods
в Kubernetes
в облачном провайдере на примере EKS
. Достаточно подробно рассматривается путь:
1) Host role
(...-2017)
2) Proxy roles
(2017–2019)
3) IRSA
(2019–2023)
4) Pod Identity
(2023-...)
Всем, привет!
Неумолимо приближаются праздники и наступление Нового года. Нам хочется уже потихоньку создать для вас новогоднее настроение (если у вас его еще нет). Для этого мы разыграем несколько наших подарков!
И так что надо сделать чтобы выиграть один из наших светильников:
К комментарию к данному посту необходимо написать оригинальное поздравление c Новым Годом для специалиста по безопасности контейнерных сред и Kubernetes
=)
- Варианты принимаем до 26 числа включительно
- Вариантов может быть несколько
- Победителей на наше усмотрение может быть несколько
- Победителей будем выбирать своим субъективным мнением команды Luntry
- C победителями свяжемся и договоримся о передаче/пересылке
Сегодня речь пойдет про trust-manager – небольшой Kubernetes operator
, который призван помочь снизить накладные расходы на управление TLS trust bundles
в ваших кластерах.
Оператор добавляет CRD Bundle
, который может считывать данные из различных источников и объединять полученные сертификаты в bundle
, готовый к использованию.trust-manager
разработан как дополнение к cert-manager, но при необходимости может использоваться и независимо от него.
Так как речь сегодня у нас пошла о тренингах/обучениях и уже как никак конец года и можно потихоньку начинать подводить итоги года, то можно сказать несколько слов и о моем тренинге "Cloud Native безопасность в Kubernetes" (1,2,3,4).
Данный тренинг я начал читать в 2021
года и уже получается 4
года! За это время он постоянно рос (с ~300
до ~540
) и настолько увеличился, что не умещается уже в рамки 3-х дней. В итоге, я решил что в таком виде я его читал последний раз в этом году. И его ждет напрашивающаяся декомпозиция ввиду большого количества материалов, опыта, историй и кейсов. (так с легкой руки я придумал себе море работы на праздники - не делайте так!)
Также на мой взгляд это очень наглядно показывает как развивается данная тема безопасности контейнеров и Kubernetes
и сколько с каждым годом в ней все больше тонкостей.
На нашем сайте Luntry в разделе Исследований мы выложили слайды и запись нашего последнего вебинара на тему "Подпись и валидация образов в Kubernetes". Всем приятного просмотра и как обычно вопросы можно задавать в комментариях или на прямую!
Всем хороших выходных и пятницы 13 ;)
Если вы используете в своей инфраструктуре confidential containers
, то статья "How your confidential containers can securely retrieve secrets?" как раз для вас.
В ней автор рассказывает как CoCo безопасно извлекают секреты, а также как устроен процесс аутентификации, resource retrieval flow
и как выглядят запросы от ворклоадов до Confidential Data Hub endpoint
.
Прием заявок на доклады на БеКон 2025!
Если мы на предыдущие конференции только приглашали докладчиков из наших клиентов, друзей и партнеров, на конкретные темы, то сейчас появляется возможность предложить свою тему самостоятельно ;)
Требования к заявке:
- Продолжительность доклада — не более 25 минут
- Тема по безопасности контейнеров и Kubernetes
- Выступление рассчитано на технических специалистов
- Доклад актуален и основан на личном опыте
- Доклад ранее нигде не был представлен
- Доклад глубоко раскрывает тему и имеет практическое применение
P.S. Анонс сделали сильно заранее, чтобы было достаточно времени продумать и подготовить тему!
11 и 12 декабря команда Luntry участвует в открытой конференции ИСП РАН в Москве.
В 2024 г. конференция посвящена 30-летию ИСП РАН, который был основан крупным советским и российским учёным В.П. Иванниковым. Участниками конференции станут эксперты отечественных и зарубежных научных и образовательных организаций, представители ведущих ИТ-компаний и государственных ведомств.
Мероприятие пройдет в Москве, в инновационном кластере «Ломоносов». Зарегистрироваться на мероприятие и ознакомиться с программой можно по ссылке.
В начале декабря вышла новая версия Calico
– 3.29
и в ней есть достаточно много мажорных изменений:
1) nftables dataplane
. nftables
использует новую реализацию nftables-based kube-proxy
(представленную в Kubernetes 1.31
) и обеспечивает совместимость с новыми функциями ядра, а также использует преимущества улучшенной безопасности, заложенные в новые функции ядра.
2) Tiered Network Policies
. Новый ресурс в OpenSource
версии Calico
, позволяет группировать политики и выстраивать их приоритеты. Более подробно об этом можно почитать тут.
3) AdminNetworkPolicy support
. Теперь Calico
поддерживает AdminNetworkPolicy
, которую должны добавить в следующих релизах. Об этом ресурсе мы рассказывали ранее на канале.
Среди инструментов (коих немного) упрощающих процесс проведения пентеста контейнерных окружений очередное пополнение – Am I Isolated.
В целом, ничего нового, очень похоже на уже давно имеющиеся botb и amicontained. Из плюсов – написан на Rust
и активно развивается.
Сейчас, например, в нём есть проверки на:
- возможность эксплуатации опасных capabilities
- возможность эксплуатации namespaces
- наличие проброшенного containerd/docker socket
- определение использования microVM
- поиск участков памяти для RWX
Начинаем эту неделю с eBPF
тематики, а точнее со свежего документа "A Security Threat Model for eBPF" от eBPF Foundation
. Этот документ будет полезен для тех, кто рассматривает внедрение технологии eBPF
в своих системах, чтобы понимать связанные с этим риски и способы их снижения.
Отдельно хотим отметить раздел "Detailed Threats and Controls
". Очевидно, что там отражены не все возможные угрозы, многие из них обобщены, описаны необходимые меры для митигации рисков.
На нашем сайте в разделе исследований стали доступны слайды и видеозапись доклада "Безопасность от виртуальных машин до контейнеров и обратно" с конференции Industrial++ 2024.
Доклад для тех кто только погружается в тему и хочет понять в чем тут вообще разница)
kondense - это проект на Go
выполненный в виде sidecar
контейнера, который помогает автоматически управлять ресурсами контейнеров в Kubernetes
без их перезапуска. На пример, освобождать не используемое количество выделенной контейнеру memory
и CPU
. Для этого используется не так давно появившееся фича InPlacePodVerticalScaling.
Многим такое полезно, но в данной реализации как по нам все омрачается правами ServiceAccount
, которыми должен владеть Pod
- это: "get", "list", "watch", "patch"
на "pod"
и (самое печальное) "create"
на "pods/exec"
(тут исходник, объясняющий зачем это)... С учетом этого также получается, что все сервисы теперь должны в своих NetworkPolicy
иметь доступ к Kubernetes API
.
Хоть проект и полезный, но с учетом вопросов ИБ к нему врят ли его можно рекомендовать. Явно нужно ждать другой реализации. Но сам факт появление подобных проектов вокруг фичи InPlacePodVerticalScaling это отлично.
Сегодняшний пост будет актуален для тех, кто использует у себя OpenShift
. А, именно – была раскрыта CVE-2024-6538, позволяющая авторизированному пользователю эксплуатировать SSRF
.
Бага была обнаружена в компоненте OpenShift console
. Для её эксплуатации достаточно отправить следующий POST
запрос:
POST /api/dev-console/proxy/internet
Full Read SSRF
, а значит получим полный ответ со всеми заголовками. Используя такой вектор атаки, злоумышленник может повлиять на другие сервисы, работающие внутри кластера и потенциально раскрыть информацию или оказать другое вредоносное воздействие на систему.
Читать полностью…