Мой коллега Сергей Канибор в процессе исследования безопасности Kubernetes наткнулся недавно на GitHub на один интересный баг и при этом еще НЕ ИСПРАВЛЕННЫЙ, который позволяет обходить определенный момент при работе PSP или Policy Engines!

Сама issue называется так - "Can bypass PodSecurityContext.SupplementalGroups by custom container image although PSP(or other policy engines) enforces the field". Название говорящее и сразу становится ясно, что речь идет только о SupplementalGroups. Наиболее критично это для multi-tenant Kubernetes cluster так как "can get access to some private directory in the hostPath volume.". И для самого обхода требуется собрать image специальным образом.

Более детально о данной проблеме и как ее воспроизвести (PoC) можно почитать в данном исследовании автора - "strict-supplementalgroups-container-runtime".

На глаза попалась статья с интересным названием “Abusing ETCD to Inject Resources and Bypass RBAC and Admission Controller Restrictions”.

Внутри разбираетcя что такое ETCD и как оно работает, как взаимодействовать с ним напрямую, а также как забрать и положить значение из key-value хранилища, так чтобы ничего не сломалось. В примере демонстрируется как можно записать значение Pod и какие ошибки при этом могут возникнуть (ну и как их пофиксить).

Громкое название, автор оправдывает в конце, напоминая, что любые ресурсы, которые деплоятся в кластер, проходят через kube-api server и соответственно подвергаются как валидации RBAC, так и Admission Controller, например в лице Policy Engine. Помещая ресурсы напрямую в ETCD, эти проверки можно обойти.

Как по мне, статья будет полезна тем, кто хочет понять как работать с ETCD, и тем, кто проводит пентест, при этом обложен различными средствами безопасности внутри кластера, но в тоже время обнаруживает Unauthenticated Access в ETCD :)

Совсем скоро (а именно Feb 1–2, 2023) состоится CloudNativeSecurityCon North America. На первый взгляд кажется что тут такого премичательного?! Ведь он уже и раньше проводился:
- Cloud Native SecurityCon North America (Oct 24–25, 2022)
- Cloud Native SecurityCon Europe (May 16–17, 2022)

Но по факту это первое такое самостоятельное мероприятие. То есть оно не проходит в рамках Kubecon и CloudNativeCon! В итоге, имеем целых 2 дня со множеством докладов по безопасности =)

Совсем недавно был пост про ChatGPT и как его можно использовать для troubleshooting в Kubernetes. Но энтузиасты пошли дальше и показали как можно запустить Кубер внутри ChatGPT. Да-да, вы не ослышались :) Стоит отметить, что этот эксперимент был вдохновлён другим экспериментом – Building A Virtual Machine inside ChatGPT.

Автор показывает как можно раскатать кластер через kubeadm прямо внутри чата (не без ошибок ChatGPT конечно, но всё же). Более того, лёгким движением руки версии Nodes обновляются с 1.20.1 до 1.21, в Pods стартуют контейнеры, и даже запущенный nginx внутри контейнера отдаёт ответ. Звучит как магия, не иначе.

Всем хороших выходных и удачных экспериментов =)

Как я уже писал, в конце прошлого года вышел Kubernetes 1.26 и там появилась такая фича как ValidatingAdmissionPolicy, позволяющая с помощью Common Expression Language выражений писать собственные политики.

Я, конечно, сомневаюсь, что уже кто-то активно использует 1.26 и включил данную alpha фичу, но все же смотреть на ее возможности - что, как и где она может конкурировать с Policy Engines уже точно можно. И лучше всего это делать на хорошо известных примерах!

Так, вот одни ребята взяли так и сделали - создали проект Kubescape Validating Admission Policy library в котором есть чуть более 20 готовых политик, типа:
- Forbidden Container Registries
- Resources memory limit and request
- Allow privilege escalation
- Immutable container filesystem
- Privileged container
- Sudo in container entrypoint
- и т.д.

Рекомендую посмотреть и сравнить с такими же политиками в Kyverno на YAML и в OPA Gatekeeper на Rego.

Top 15 Kubectl plugins for security engineers

Отличная подборка krew security плагинов для работы с Kubernetes. Мне приходилось иметь дело со следующими: RBAC-tool, Access-matrix, Rolesum, np-viewer, ksniff, Inspektor-Gadget.

На текущий момент, насчитывается более 200 плагинов krew в официальном репозитории. Но стоит не забывать, что вместе с удобством при их использовании, они также привносят security implications, такие как:

- Plugin vulnerabilities
- Insecure plugin installation
- Privilege escalation
- Data leakage

Чтобы избежать этих рисков, важно устаналивать плагины только из доверенных источников и регулярно обновлять их.

В официальном блоге Kubernetes вышла крутая статья "Consider All Microservices Vulnerable — And Monitor Their Behavior", посвящённая Security-Behavior Analysis!

Основной смысл: Наблюдайте и контролируйте поведение микросервисов и это уберет security gap между вами и атакующим, где он на шаг впереди.

Золотая цитата: "However, the year-by-year growth in cyber investments does not result in a parallel reduction in cyber incidents. Instead, the number of cyber incidents continues to grow annually. Evidently, organizations are doomed to fail in this struggle - no matter how much effort is made to detect and remove cyber weaknesses from deployed services, it seems offenders always have the upper hand."

Я несказанно рад, что такие же мысли и взгляды как у меня есть и у других людей в индустрии =)

Просто MUST READ для всех кто занимается безопасностью микросервисов и хочет этот делать качественно и правильно с учетом окружения!

P.S. Это именно то что мы с командой заложили в наш Luntry в модуль Runtime Security

Сегодня хочется поделиться ресурсом –“Container Security Site”. Сайт реально является кладезью полезной информации о container security.

На канале уже не раз упоминалось о подобных ресурсах, например тут (он кстати переехал сюда) и тут. Более того, о данном ресурсе вскользь упоминалось в этом посте, в контексте подборки Container CVE List.

В источнике затрагиваются все возможные полезные темы:

- General information
- Information for Attackers
- information for Defenders
- Security research

Ресурс будет крайне полезен как для Blue, так и для Red Team.

По мне очень смешное напоминание о том, что безопасность это комплексный процесс. И относительно безопасности контейнеров, Kubernetes стоит помнить и о: RBAC, Runtime Security, Audit Log, Network Policy и политиках PolicyEngine.

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

На канале не раз упоминалось о важности сбора и анализа SBOM (1,2,3). Более того, этот функционал есть и в нашем Luntry. При сборе SBOM, довольно трудно понять насколько полноценную информацию удаётся собрать.

Сегодня хочу поделиться инструментом, который поможет количественно оценить сгенерированный SBOM. В sbom-scorecard довольно большая система метрик, по которым выносится конечная оценка SBOM (она еще развивается и дополняется):

- Spec compliant
- Generation Info
- IDs
- Versions
- Licenses

Тулзу можно попробовать и без установки. Для этого достаточно перейти на сайт и загрузить SBOM.

Наше с коллегой выступление "eBPF в production-условиях" с конференции HighLoad++ Foundation 2022 в Москве стало доступно и в текстовом формате на Хабре (слайды и видео доступны тут). Материал до сих пор актуальный, в данном вопросе пока ничего не поменялось.

Почти год назад на канале был пост, в котором рассказывалось каким образом можно посмотреть и где найти в коде встроенные системные Roles, ClusterRoles, RoleBindings и ClusterRoleBindings в Kubernetes.

Недавно, мне самому понадобилось собрать такую информацию – и решение проблемы оказалось очень простым! Оказывается, что все системные Roles, ClusterRoles, RoleBindings и ClusterRoleBindings имеют лейбл kubernetes.io/bootstrapping=rbac-defaults. Поэтому для того чтобы получить список встроенных объектов RBAC достаточно выполнить команду:

kubectl get roles,rolebindings,clusterroles,clusterrolebindings -A -l kubernetes.io/bootstrapping=rbac-defaults

Kubernetes постоянно развивается – где-то заезжают новые фичи, где-то отказываются от того, что не зашло. Это также отражается и на встроенных RBAC объектах. Если сравнить две мажорные версии кубера, можно заметить, что количество ClusterRoles в них отличается.

P.S. Читайте документацию =)

P.S.S. Лейбл можно накинуть на любой не кастомный объект RBAC

Очень оперативно на YouTube уже стали доступны выступления с первого дня CloudNativeSecurityCon 2023 в Seattle (это уже порядка 45 докладов), о котором я писал недавно. Думаю, что со второго дня все доклады будут доступны уже завтра! Также на сайте в разделе программа для некоторых докладов доступны и слайды ;)

На днях вышла новая версия Kyverno – 1.9. Нововведений достаточно много, но интересными мне показались следующие:

– Policy Exceptions . Это новый CRD, в котором можно указывать исключения для политик. По сути, это такой своего рода bypass, для уже действующих политик в кластере. Безусловно, возможность создания таких ресурсов нужно ограничивать RBAC.

– Cleanup Policies. Еще один новый CRD. Позволяет подчищать кластер от ненужных ресурсов, поддерживает JMESPath и всё это работает в формате CronJob – по заданному расписанию.

Настоятельно рекомендую обновиться тем, кто уже использует Policy Engine у себя в кластере, а тем, кто ещё не дошел до этого – почитать о его пользе и необходимости [1, 2], при выстраивании Defence-in-Depth в Kubernetes.

Доносятся последние отголоски наших прошлогодних выступлений - на Хабре стала доступна статья по мотивом выступления "SOAR в Kubernetes малой кровью".

И мы уже с нашей командой Luntry создаем новый уникальный контент на этот год! Среди тем которым мы уже точно затронем:
- Причудливости и премудрости Kubernetes RBAC
- Альтернативный взгляд на матрицу угроз для Kubernetes
- Жизнь с AppArmor в Kubernetes
- Специализированный образ для pentest в Kubernetes
- Уровни зрелости при работе с уязвимостями в образах контейнеров

При этом уже есть первый анонс - "Локальная инфраструктура для разработки k8s-native ПО", что прозвучит на DevOpsConf 2023!

Сегодня хочу рассказать про очень крутой dashboard для Grafana – Cilium Policy Verdicts. Если вы смотрели доклады с прошедшего CloudNativeSecurityCon 2023, то должны были его заметить :)

С помощью него можно удобно смотреть в каких моментах Egress или Ingress политика пропустила трафик, а в каких нет. Будет очень полезным, если вы хотите убедится в том, как работают сетевые политики, примененные к workloads. Есть удобные фильтры по namespace.

Чтобы всё заработало, предварительно, при установке Cilium нужно включить метрику hubble_policy_verdicts_total.

В официальной документации Kubernetes есть замечательная страничка "Deprecated API Migration Guide", которая будет полезна как опытным специалистам, так и только начинающим. Kubernetes активно развивается и ряд фичей (API) не проходят испытание временем по тем или иным причинам (порой совсем непонятным).

И очень важно следить чтобы при установке тех или иных решений - при обновлении, при переезде и т.д. Не зная данного момента можно погрязнуть в отладке данного момента.

Например, Helm у себя в секретах в списках релизов чарта хранит все манифесты. В итоге в процессе установки новой версии чарта (обновления чарта) после обновления Kubernetes, обновляем чарт на новые версии, манифесты, задеплоенные в Kubernetes он обновляет самостоятельно. При этом то, что Helm положил в историю релизов остается нетронутым. При апгрейде запускается процедура трехстороннего мержа, Helm достает из секретов сохраненные манифесты с deprecated version и пытается отдать их API куба. И в результате все падает с невразумительными ошибками …

Также стоит знать что есть и разные вспомогательные инструменты: kube-depre, pluto, kubepug, kube-no-trouble, ...

P.S. За идею поста и почти за весь пост - спасибо читателю канала ;)

Если по какой-то причине вам нужно мигрировать с политик OPA Gatekeeper на Kyverno – вот отличная заметка о том, как это сделать.

Схема довольно простая: ставим в кластер Kyverno (OPA уже был), раскатываем соответствующие политики Kyverno в audit режиме, смотрим на то как они себя ведут, если всё ок – переводим политики Kyverno в enforce режим, а OPA политики сносим.

Но не стоит забывать о существовании Mutation policy, ведь там всё может быть немного сложнее. Дело в том, что две работающие Mutation политики от разных Policy Engine могут привести к перезаписи объектов. Для таких случаев, и вообще любых других случаев, где вы сомневаетесь в том как работает политика есть команда kyverno test (почитать про неё можно здесь).

Также авторы прикладывают таблицу смапленных политик Kyverno и OPA Gatekeeper.

Маленькая познавательная статья "The life of a DNS query in Kubernetes" о работе DNS в K8s.

Будет полезна как для общего понимания работы приложений в Kubernetes, так и для проведения сетевых атак в нем ;)

Вы знали, что можно отслеживать кто и когда пуллит ваши docker образы? В статье “Fun with Containers – Adding tracking to your images” как раз рассказывается об этом.

Тут очень важно отметить, что используется OCI image spec, а не дефолтный образ формата Docker, который обычно получается после сборки. OCI image spec довольно обширна и включает в себя большое количество компонентов. Одним из таких компонентов является denoscriptor с необязательным (!) полем urls, куда как раз-таки можно подложить вебхук.

В статье автор показывает, как модифицировать образ, добавив туда дополнительное поле, пофиксить возникающие из-за этого проблемы и отгрузить image в registry. В конце приводятся примеры прилетающих запросов.

Думаю, что данная фича будет интересна как белой так и тёмной стороне – одним, чтобы отслеживать, что образы никуда не утекли за пределы инфраструктуры, другим, чтобы детектить возможных новых жертв.