Продолжим тему предыдущего поста про организацию MITRE, а точнее про их матрицы. Как правило они обновляют их два раза в год, в том числе и после конференции ATT&CKCON 4.0. Матрица Enterprise обновилась, а это значит, что и Container Matrix тоже.

Были добавлены следующие техники: Account Manipulation, Create Account, Data Destruction и Endpoint Denial of Service. Несмотря на то, что матрица посвящена контейнерам, в ней всё чаще встречаются прямые отсылки к Kubernetes (что не может не радовать).

16 ноября в Москве пройдет конференция VK Kubernetes Conf, посвященная она как не сложно догадаться Kubernetes. Мы не могли остаться в стороне : Сергей Канибор (сотрудник Luntry и один из авторов данного канала) выступит на мероприятии с докладом «Экскурсия по матрицам угроз для контейнеров и Kubernetes» (последними нашим постам [1,2] мы вас уже немножко ввели в контекст). Еще вы можете вспомнить наш недавний релиз инструмента MTKPI и там мы тоже мапили его возможности на матрицу угроз (рекомендуем освежить в памяти).

Так Сергей подробно расскажет об основных матрицах угроз для контейнеров и K8s, об их отличиях и недостатка, а также на примерах покажет как это может работать и не работать ...

P.S. Таким образом с нами можно встретиться и пообщаться 14-15 ноября на SOC Forum, а 16 ноября на VK Kubernetes Conf!

Начнем эту короткую неделею с интересного прототипа kube-rebac-authorizer.

Важные моменты:
1) Kubernetes поддерживает множество authorizers и они могут работать в цепочке
2) Классическая, всем знакомая цепочка состоит из двух authorizers: Node и RBAC
3) Kubernetes позволяет заменять и добавлять собственные authorizers через webhook

Данный проект это как раз демонстрация реализация собственного authorizer! Его уникальные черты:
- Реализует Relation-based Access Control (ReBAC)
- ReBAC это развитие RBAC и ABAC
- Базируется на идеи Google Zanzibar
- В основе OpenSource реализации CNCF project OpenFGA
- Структура графа с узлами (субъекты, объекты) и ребрами (права доступа)
- Проект объединяет Node и RBAC authorizers в один компонент
- Дает возможность fine-grained доступа

Видео доклада "Beyond RBAC: Implementing Relation-based Access Control for Kubernetes with OpenFGA" про этот прототип с Cloud Native Rejekts NA 2023 (забавный факт - конфа для докладов, которые не приняли KubeCon + CloudNativeCon).

Совсем недавно мы рассказывали о докладе "Post-Exploiting a Compromised ETCD - Luis Toro Puig, NCC Group" с прошедшего Kubecon China 2023.

В докладе был упомянут инструмент – kubetcd, и вчера он стал доступен для всех желающих. Тулза по факту является обёрткой над auger и умеет создавать новые Pods, обходить AdmissionControllers и ещё много чего в скомпрометированном ETCD. Также стало доступно видео с выступления и статья Post-exploiting a compromised etcd – Full control over the cluster and its nodes от автора доклада.

Отдельно хочется поблагодарить самого автора (и по совместительству подписчика нашего канала)– Luis Toro Puig. Задавайте свои вопросы по докладу и инструменту в комментариях на английском языке, а он постарается ответить на них ;)

Как мы уже неоднократно рассказывали одним из способов уменьшить «шум» от сканеров известных уязвимостей — это уменьшить количество компонентов, которые лежат в образе. И к этому глобально можно подойти 2 способами (multi-stage сборку рассматриваем как само собой разумеющееся):
1) На основе специализированного образа (scratch, alpine, distroless, chainguard)
2) На основе динамического анализа

Если о первом способе мы много пишем и многие знают, то про второй как раз нет. Ввиду того что нужен специальный инструментарий для этого. И такой инструментарий как раз есть - проект Slim (или SlimToolkit ранее известный как DockerSlim).

Проект позволяет посмотреть, что действительно используется во время работы и только это и оставить в итоговом образе! Но как вы понимаете тут очень важно (как и в случае любого динамического анализа) это покрытие кода тестами ...

Но сегодня хотелось бы отметить и еще одну новую экспериментальную фичу/флаг --obfuscate-metadata, которая вдохновлена докладом "Malicious Compliance" (мы писали о нем тут и тут). Да, он автоматом обфусцирует (реализация тут) данные о пакетах python, ruby, node и сканеры не видят уязвимости ;)

И повторим важную мысль относительно сканеров уязвимостей: "Все подходы, анализы на базе статического анализа позволяют защититься только лишь от легитимного пользователя, но не являются никакой помехой для вредоносного"

kubernetes-for-soc – репозиторий, призванный ускорить процесс обучения аналитиков SOC, позволив им быстро освоить необходимые основные понятия и знания. Быстрый темп развития технологий оставляет SOC аналитикам мало времени для приобретения глубоких знаний и опыта, необходимых для эффективной защиты и/или мониторинга внедрений Kubernetes.

Репозиторий состоит из двух частей: threat model и observability (скоро обещают добавить третью часть – checklist). В нём отражены основные threats, threat actors, attack vectors и attack path присущие Kubernetes.

Но всё-таки это нельзя назвать полноценным руководством. Однако для SOC аналитиков, которые никогда не трогали Kubernetes будет полезно.

Хотим напомнить, что уже на следующей неделе, а именно 14 и 15 ноября нас можно будет найти на SOC-Forum 2023: там мы представим два доклада «SOC в контейнерах» и «EDR vs Containers: актуальные проблемы».

openSUSE MicroOS - еще одна container specific OS. Если Flatcar, Talos у многих уже на слуху, то эта ОС нет. По своей концепции она ближе к Flatcar. А так обладает всеми свойствами присущими специализированным ОС для запуска контейнеров. Видно, что направление развивается и все больше игроков/проектов появляется. Возможно, кому-то приглянется именно это реализации (в первую очередь ставим на пользователей Rancher).

Так уже в принципе глупо отрицать тот факт, что сегодня при построении контейнерной инфраструктуры требуется специализированная ОС, а не ОС общего назначения, чтобы получиться все преимущества от использования контейнеров как для сопровождения, так и для обеспечения безопасности.

Уже завтра стартует SOC Forum 2023, где наша команда Luntry представит 2 доклада. Также там у нас будет стенд с интересными подарками, которые можно получить за участие в небольшой игре/активности для которой мы приготовили вот такие карточки. Так что все кто будет на конференции - подходите, участвуйте, спрашивайте про безопасность контейнеров и Kubernetes!

С недавнего времени Kyverno теперь может валидировать не только Kubernetes, но и впринципе любые ресурсы. Мы уже рассказывали о возможностях Kyverno [1,2] и даже вкратце затрагивали проект json-validator, который скорее всего вылился в новый – kyverno-json.

Сейчас авторы предлагают использовать новый проект для валидации:

- Terraform files
- Dockerfiles
- Cloud configurations
- Service authorization requests

kyverno-json можно запускать как CLI, веб-приложение с REST API или использовать в качестве библиотеки Golang. Уже сейчас доступна небольшая библиотека политик для AWS, ECS и Dockerfile. Также есть возможность попробовать новый проект онлайн – по ссылке доступен playground.

Мало кто знает, но в документации Google Cloud есть прям замечательная (и очень большая) библиотека правил для OPA Gatekeeper - их там порядка 90! При этом они идут с примерами как удовлетворяющих их ресурсов, так и нет (считай тесты).

Отличная библиотека для вдохновения и оценки собственного набора политик. При желании тоже самое можно перенести и на Kyverno.

На недавно прошедшей конференции EnvoyCon был представлен довольно интересный доклад на тему security, а именно – Envoy Gateway End User Threat Model Report: Raising Awareness of Gateway API Security.

Также автор доклада поделился репозиторием созданным по мотивам доклада, где рассмотрел Compromised Proxy Scenario, Compromised Controller Scenario, нарисовал возможные деревья атак и приложил k8s ресурсы для воспроизведения своей демо из доклада

Напомним, что сегодня наша команда Luntry (достаточно в большом составе и оба авторы данного канала будут на сцене) будет на VK Kubernetes Conf! Там мы и доклад представим и в круглом столе про развитие Kubernetes поучаствуем (в следующем году ему будет 10 лет если отсчитывать от Initial release)!

Будем рады пообщаться лично =)

Недавно наши хорошие товарищи поделились (а теперь и мы с вами) своим проектом, которые они уже сами у себя используют более чем 2 года.

Проект называется k8s-calico-networksets-controller и он по сути добавляет поддержку FQDN в NetworkPolicy от CNI Calico!

Вся магия происходит с помощью selector в NetworkPolicy с определённым label и через создание/обновление Calico NetworkSet.

Если вам не хватало поддержки FQDN в NetworkPolicy от CNI Calico, то это решение для вас)

P.S. Всем хороших выходных!

В конце прошлой недели вышел Kyverno 1.11 с новыми возможностями:

1) Добавлен новый тип подправила validate.cel, позволяющий использовать выражения Common Expression Language (CEL) для проверки ресурсов.
2) Улучшения в Policy Report: теперь для каждого ресурса создается PolicyReport, который автоматически удаляется при удалении соответствующего ресурса. AdmissionReports и BackgroundScanReports теперь считаются эфемерными и очищаются после объединения в итоговые отчеты.
3) Обновления Notary: добавлена поддержка проверки аттестатов OCI 1.1.
4) Поддержка Cosign 2.0: теперь проверка Tlogs и SCTs включена по умолчанию и может быть отключена через атрибуты в политике.
5) Кэширование проверки образов для ускорения процесса.
6) Возможность очистки ресурсов через TTL label cleanup.kyverno.io/ttl. Присвоение метки ресурсу с необходимыми правами приведет к его удалению в указанное время.
7) Переработка CLI и новая схема тестирования.

Наш хороший товарищ Павел Сорокин (вы могли его видеть среди докладчиков на нашей конференции БЕКОН) у себя на канале сделал замечательную серию очень технических постов про hostPID: true и --pid=host:

Часть 1
Часть 2
Часть 3
Часть 4

А именно он разбирается к каким последствиям может привести наличие данных параметров и какие механизмы безопасности (Yama, AppArmor) каким образом могут это ограничить.

Также можно вспомнить про замечательный репозиторий BadPods и там также глянуть эту тему ;)

Заглянув в release notes к бета-версии Containerd v2, мы с радостью увидели изменение, запрещающее доступ к io_uring по умолчанию.

io_uring был использован во многих уязвимостей ядра для повышения привилегий и побега из контейнера, о чем мы уже как-то рассказывали на канале, поэтому, если нет необходимости, очевидно, что его следует отключить. Мы уверены, что со временем эта функция стабилизируется и улучшится, но на данный момент она кажется довольно рискованной.

Помимо этого изменения, хотелось бы отметить ещё пару:

- Add support for userns in stateless and stateful pods with idmap mounts (KEP-127, k8s >= 1.27)
- Add support for user namespaces (KEP-127)

Совсем недавно прошла конференция KubeCon + CloudNativeCon North America 2023 и уже стали доступны и слайды и видео на их канале. Как всегда там море всего интересного!

Пока отдельно выделим один доклад "A Wind of Change for Threat Detection" от ребят из Apple, посвящённый проблемам rule-based detections в runtime в контейнерных средах. Как мы и говорим уже не один год все идет к поведенческому анализу.

И отдельно стоит отметить в первые проходившую Multi-TenancyCon NA 2023, которая отдельно проводилась в эти же дни. И видно как тема правильной организации multi-tenancy становиться актуальной для большого числа компаний.

P.S. В комментариях пишите какие доклады больше всего понравились вам!

Kubelet Serving Certificate Approver – репозиторий с контроллером, который аппрувит kubernetes-io/kubelet-serving CSR, используемый kubelet для обслуживания TLS endpoint. Проект поддерживает версии Kubernetes 1.22 - 1.28.

Контроллер может быть полезен, если:

- вы хотите установить безопасное общение с endpoint kubelet (с точки зрения СА)
- подписанные serving сертификаты рассматриваются сервером API как действительные сертификаты обслуживания kubelet
- не хотите использовать флаг --kubelet-insecure-tls во время установки metrics-server

К слову сказать, оригинальная идея принадлежит проекту kubelet-rubber-stamp, который не поддерживается уже 3 года.

Недавно давали интервью по поводу безопасности в Kubernetes и концепции ZeroTrust. Почитать можно тут, а свое мнение оставить в комментариях к данному посту ;)

Так предотвращать, дешевле чем расследовать =)

Всем хороших выходных!

Так как нашей команде Luntry часто приходится участвовать в различных проектах по безопасности Kubernetes систем: аудиты, пентесты, архитектурные проекты. То приходится порой думать о некоторых моментах, к которым просто так не придешь, никогда об этом не задумываясь. Одним из таких последних моментов был момент, когда требовалось понять стоит ли определенные высокопривелигерованные микросервисы (там хороший SA) располагать в одном Namespace или расселить на разные. При решении этой задачи как раз и пригодился наш атакующий опыт.

Смысл заключается в том, что если у злоумышленника на Node есть возможность создать Pod в таком Namespace (где и эти высокопривелигерованные сервисы), даже с учетом того что стоит множества правильных политик PolicyEnginе (против Bad Pods и тд), то у него все равно остаётся возможность смонтировать внутрь такого Pod интересующий его SA из того же самого Namespace! Далее когда он смонтируется туда, то можно смело забирать его с Node ...

Как митигейшены можно сделать следующее:
1) Чтобы уменьшить риск компрометации, критичные сервисы разделать по Namespaces
2) Namespaces c критичными/инфраструктурными сервисами привязывать только к определенным инфраструктурным Nodes
3) Писать политики PolicyEngine, которые проверяют использование критичных SA, только в определенных сервисах

P.S. Еще была крутая идея для атаки - все это провернуть через StaticPod, но там нельзя ссылать на другие ресурсы (на тот же SA)…

P.S.S. Ближайшие дни мы на HighLoad++ 2023 Msk и будем рады пообщаться лично =)

Казалось бы, инструмент IceKube – что-то новое и интересное в мире Kubernetes Security, но как бы не так.

Тулза умеет искать возможные attack path в кластере от самых минимальных привилегий до cluster-admin. Результаты своей работы отображает в графовой БД – Neo4j. На этом моменте нельзя не упомянуть инструмент, о котором мы рассказывали совсем недавно, и который, очевидно, был взят за основу – KubeHound.

Суть работы у IceKube точно такая же, даже вектора attack path одинаковые и ничего нового авторы не придумали. Но всё-таки отличия у инструментов есть – написаны на разных языках и IceKube имеет пару правил, относящихся к Managed Kubernetes, а именно AKS и AWS.

Для тех, кто хочет детальнее изучить инструмент, посмотреть на примеры и ознакомиться с проблематикой – рекомендуем статью "IceKube: Finding complex attack paths in Kubernetes clusters" от авторов тулзы.