k8s (in)security

2022-04-21 08:30:16 Участник Kubernetes Release team в twitter сообщил о важно и крутом изменении с точки зрения безопасности supply chain для Kubernetes. А именно о том что сейчас можно не только SBOM образов Kubernetes посмотреть , но и проверить их подписи с помощью cosign!

Видео данного процесса можно посмотреть тут. А попробовать самостоятельно с помощью следующего скрипта:

curl -Ls https://sbom.k8s.io$(curl -Ls https://dl.k8s.io/release/latest.txt)/release | grep 'PackageName: http://k8s.gcr.io' | awk '{print $2}' > images.txt
input=images.txt
while IFS= read -r image
do
COSIGN_EXPERIMENTAL=1 cosign verify "$image"
done < "$input" | jq


Постепенно Kubernetes идет к SLSA Level 2. Открыть/Комментировать

2022-04-20 15:00:01 Открыть/Комментировать

2022-04-20 08:30:10 Небольшая заметка "Automation is the serialization of understanding and understanding is based on the fundamentals, not the tools" с очень правильным посылом, который я часто транслирую тут на канале.

Понимайте как и что у вас устроено и работает, понимайте что и где у вас происходит. Это позволит не только грамотно cо всем работать, автоматизировать, но и позволит избавиться от слепых зон, что может использовать атакующий.

Security through understanding/observability. Открыть/Комментировать

2022-04-19 09:00:46 Stratus Red Team - это Atomic Red Team, но только для Cloud.

Его задача быстро и просто выполнять атакующие техники (по сути, тесты смапленные на MITRE ATT&CK), чтобы при внедрении threat detection правил проверить насколько хороши эти ваши правила.

На текущий момент проект поддерживает:
- AWS
- Kubernetes

Поддержка Azure и GCP только в планах. Нас же интересуют в первую очередь Kubernetes и там сейчас есть поддержка 7 техник (перечислены на скриншоте). В некоторых случаях даже есть примеры того, как можно обнаруживать ту или иную атаку (в основном по Kubernetes Audit Log). Но отмечу, что все это так или иначе частные случаи и при более продвинутом атакующем, обойти это будет не сложно. Открыть/Комментировать

2022-04-18 08:55:57 В прошлую пятницу проводил вебинар "Методично закрываем вопросы безопасности в Kubernetes" на площадке СЛЁРМ и запись уже доступна. На мой взгляд это будет полезно посмотреть тем, кто не в курсе что такое или просто руки не доходили поработать с проектами:
- Calico (NetworkPolicy, GlobalNetworkPolicy, ...)
- Istio (AuthorizationPolicy, PeerAuthentication, RequestAuthentication, Sidecar, ...)
- Kyverno (ClusterPolicy, Policy, PolicyReport, ClusterPolicyReport,…)
- Gatekeeper OPA (ConstraintTemplate, Constraint, …)
- RBAC Manager (RBACDefinition)
- Starboard (CISKubeBenchReport, ConfigAuditReport, VulnerabilityReport, ClusterComplianceReport,…)
- Kubernetes Security Profiles Operator (AppArmorProfile, SelinuxProfile, SeccompProfile, ProfileBinding, ...)

За достаточно непродолжительный промежуток времени вы посмотрите, как и в чем эти OpenSource проекты могут помочь в безопасности и как они влияют на кластер и приложения в целом. А все это изучать и наблюдать мы будем через Luntry, так что это будет и полезно тем, кто сейчас проводят пилот ;)

P.S. На прошлой неделе запустил два опроса [1,2], если еще не ответили, то время еще есть - это важно для понимания состояния нашего сообщества и индустрии. Открыть/Комментировать

2022-04-15 09:00:49 Aggregated ClusterRoles это особый тип ClusterRole. Фишка данной роли заключается в том, что в ней вообще не описываются права доступа, а прописывается из каких других ClusterRole (по labels) нужно скопировать права в нее! Для этого есть специальный раздел в описании aggregationRule. А всю магию за пользователя делает контроллер из control plane. Естественно, если в "зависимых" ролях права меняются, то и в этой агрегированной это также имеет отражение.

Сам Kubernetes это использует, чтобы для некоторых встроенных ролей давать права на CustomResourceDefinitions (кастомные ресурсы).

Не знаю использует это кто-то у себя еще, но было бы интересно услышать в комментариях use-cases. Открыть/Комментировать

2022-04-13 08:40:34 Немного анонсов offline выступлений нашей команды Luntry на конференциях. Пока у нас сформировалось вот такое расписание:
- 13-14 мая HighLoad++ с докладом "eBPF в production-условиях"
- 18–19 мая PHDays с докладом "NetworkPolicy - родной межсетевой экран Kubernetes"
- 13-14 июня DevOpsConf с докладом "SOAR в Kubernetes малой кровью"

Как всегда буду рад познакомиться и пообщаться лично!

А самое ближайшее мероприятие будет onlinе и это будет вебинар на площадке СЛЁРМ в эту пятницу в 19:00 и там будет тема "Методично закрываем вопросы безопасности в Kubernetes". И там мы посмотрим на различные бесплатные kubernetes operators связанные с безопасностью и как они могут помочь повысить уровень безопасности кластера и микросервисов.

P.S. Идею со стикерпаком я не забросил и работаю над ним ;) Открыть/Комментировать

2022-04-11 09:00:12 sa-hunter - скрипт на python, позволяющая cкоррелировать какие Pods какие ServiceAccounts имеют и что у них за права через RoleBindings и ClusterRolesBindings, обращаясь к kubernetes api. При это для managed Kubernetes данный инструмент понимает еще и service account annotations, которые назначают IAM в EKS и GKE.

В результате в выводе можно получить:
1) Какой SA в каких Pods на каких Nodes с какими правами сейчас работает
2) На каких Nodes какие SA сейчас присутствуют

То есть инструмент заточен на поиск мощных/привилегированных SA, что может быть полезно как на pentest, так и на CTF. Нужно явно отметить отличие данного инструмента от подобных - он не просто показывает какой SA какое права имеет, а еще и показывает, где он сейчас и кем на кластере используется. Пример использования можно посмотреть в исследовании "Container Escape to Shadow Admin: GKE Autopilot Vulnerabilities".

Это хорошее дополнение к kubeletctl, который позволяет собирать service account tokens, общаясь с kubelet. Открыть/Комментировать

2022-04-06 09:01:15 Хотите спокойно, удобно проанализировать сетевые данные кластера Kubernetes в своем любимом Wireshark но не знаете как?

Проект PacketStreamer спешит на помощь. Он позволит снять сетевые пакеты с кластера и записать их pcap файл.

Так эти данные можно в последствии использовать для forensics и anomaly detection. Открыть/Комментировать

2022-04-04 08:56:08 Давайте рассмотрим ситуацию:
1) Один Kubernetes кластер.
2) Данный кластер имеет Multi-Tenancy на уровне namespaces. Тоесть отдельные окружения (DEV,TEST,STAGE,PROD) это просто отдельные namespaces.
3) Разрешено использовать images только с внутренних/разрешенных Image Registry для повышения безопасности.
4) По best practices для каждого окружения (DEV,TEST,STAGE,PROD - в нашем случае это namespaces) должен быть отдельный Image Registry - иначе можно получить, на пример, что то такое.

Как такое организовать?

Конечно, с помощью PolicyEngine! В качестве примера рассмотрим на Kyverno, который позволяет это сделать 2 способами:
1) Берем "Restrict Image Registries" политику и делаем ее kind не ClusterPolicy, а просто Policy и указываем в каком namespace она должна действовать и так для каждого namespace будет своя политика.
2) Берем "Advanced Restrict Image Registries" политику, добавляем соответствующие annotation к namespaces и создаем специальный ConfigMap. Данная политика хоть и ClusterPolicy, но умеет учитывать информацию из сторонних источников, где указано какие Image Registry в каких namespaces разрешены.

При такой организации уровень безопасности в кластере будет еще выше! Открыть/Комментировать