Буквально вчера вышел замечательный whitepaper “All About That Base Image”, который посвящён безопасности популярных базовых образов - image security если хотите и уязвимостям в них.

Авторы в документе задаются вопросом: "Is it possible, though, to have a base image without vulnerabilities?" и помогают грамотно подойти к выбору базового образа для ваших контейнеров. Основными критериями выбора/поиска являются:
- Наличие малого или нулевого количества известных уязвимостей в образе
- Плюсом будет наличие SBOM
- Плюсом будет наличие цифровой подписи

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

Talos это специализированная OS для Kubernetes и она наконец достигла версии 1.0! Отличительные моменты данной OS:
- minimal
- secure
- immutable

И при этом все управление идете через API - никаких shell или interactive console на Nodes, а также никаких скриптов, а только декларативные конфиги и все! При этом система отлично поддерживает Cluster API [1,2]! Зачем вообще в 2022 ходить на Nodes и тратить время инженеров, когда проще и быстрее поднять чистую Node и перекатить нагрузку туда?!

Я честно не знаю компаний, которые уже используют Talos (если используете пишите в комментариях), но общаясь с инженерами ведущих IT-компаний, могу сказать, что за проектом они пристально наблюдают ;)

Облачные гиганты уже используют свои собственные OS: Container-Optimized OS у Google, Bottlerocket у Amazon. Как по мне Talos это шаг в туже сторону, но еще дальше и по направлению к Kubernetes.

Live demo можно посмотреть в этом видео.

Не знаю как вы, но я парой люблю возвращаться к какой-либо старой/устоявшейся теме и переосмыслять ее необходимость/важность в текущих реалиях – время идет, все меняется. И так я тут последнее время все раздумывал: "А настолько ли важен Kubernetes Audit Log сегодня для безопасности?!" ...

Пока я прихожу к выводу, что на сегодняшний день не так уж и важен (сразу оговорюсь что речь идет о зрелых компаниях)! Мои аргументы:
1) Kubernetes ресурсы выкатывает не человек, а какая-то система (‘GitOps’ подходы и операторы и тд) выкатки в компании из Git по тем или иным правилам и в log мы всегда видим в принципе что действия совершены он аккаунта данной системы (часть замысла аудита теряется - установка авторства). Так можно либо из Git узнать кто какие изменения делал или обогатить Kubernetes ресурс теми или иными annotations для создания контекста операции.
2) Благодаря PolicyEngine мы можем очень просто и гибко аудировать, и даже предотвращать любую нежелательную операцию в момент ее возникновения - AdmissionReview содержит всю необходимую информацию. В случае Kubernetes Audit Log каждый раз при изменении политики аудита нужно перезапускать kubernetesapi. А в случае managed Kubernetes так мы вообще, как пользователи не можем влиять на политику аудита и, на пример, можем аудировать действия с CustomResources вообще (часть замысла аудита теряется - не полнота картины) ... Не зря же в CNCF много усилий вложил в концепцию, описанную в "Kubernetes Policy Management Paper".

Если у вас есть аргументы За или Против моих, то с удовольствием почитаю в комментариях, возможно что я что-то упускаю из виду.

P.S. Отдельно отмечу, что не стоит это воспринимать как призыв к отказу от Kubernetes Audit Log. Безопасность вещь комплексная ;)

Давайте рассмотрим ситуацию:
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 разрешены.

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

Сегодня рубрика "Знаете ли вы что ... ?"

Думаю, многие из нас в курсе и привыкли к тому, что NetworkPolicy связаны с Pod с помощью labels через podSelector и/или namespaceSelector.

Но на самом деле это не единственный способ (по крайней мере в CNI Calico) - там еще есть возможность привязать NetworkPolicy к:
1) ServiceAccount по имени или labels - таким образом NetworkPolicy применяется к endpoints, запущенным под соответствующим ServiceAccount.
2) Service по имени или namespace - по той же логике получается, что NetworkPolicy применяется к endpoints, привязанным к указанному Service

Честно я лично никогда такие selectors не использовал, а вы?)

Хотите спокойно, удобно проанализировать сетевые данные кластера Kubernetes в своем любимом Wireshark но не знаете как?

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

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

Интересный блогпост "Intro to OCI Reference Types" о OCI specifications и ее изменении с учетом добавлении новой информации об образе - на пример, подписей (signatures) или SBOM (Software Bill of Materials).

На пример, сейчас утилита cosign для хранения подписи образа добавляет новый артефакт в тот же самый registry (как мы помним они всеядные) отдельным файлом. А далее при проверке этот файл ищется по определённому формату имении и используется в проверке. В общем такой хитрый хак как связать образ с дополнительной инфой.

Для решения это задачки была создана OCI Reference Types Working Group, которая и смотрит как можно к этому поступится и сделать стандартизирована для любого дополнительного артефакта для образа. Сейчас они рассматривают 4 предложения:
1) Defines a new artifact manifest and corresponding referrers extension API
2) Add "reference" field to existing schemas
3) Create Node manifest
4) No Changes (то как и делает сейчас cosign, но строго задекларировать это)

Самая большая проблема тут это естественно обратная совместить ...

Не знаю как именно, но для безопасности очень важно чтобы signatures и SBOM стали частью образа — это упростит и улучшит многие моменты связанные с ИБ.

Недавно я был гостем у СЛЁРМ на выпуске "Обеспечение безопасности в текущих условиях: что делать с opensource". Естественно, мы там затрагивали и тему SBOM. Нужно понимать, что он полезен не только для контроля лицензий в используемых компонентах и проверки сторонних зависимостей на известные уязвимости. Но и может помочь в случае, если вдруг в какую-то библиотеку в какой-то версии добавят вредоносный код! В таком случае вы сможете определить используется ли где-то у вас данная библиотека или нет. Под такие кейсы не создают CVE и сканеры уязвимостей такое естественно не найдут ...

P.S. На следующей неделе начнем проводить различные опросы по Kubernetes и его безопасности, как никак нас тут уже собралось 3000 человек. Если вам что-то интересно узнать у аудитории данного канала (а специалисты тут собрались отличные), то предлагайте свои опросы в комментариях ;)

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.

Статья "Kubernetes RBAC: How to Avoid Privilege Escalation via Certificate Signing" это статья о том, как с помощью Certificate Signing Request (CSR) API можно повысить свои привилегии в Kubernetes кластере.

По сути, CSR API позволяет (одна из возможностей) подписывать сертификаты, которые могут быть использованы пользователями для аутентификации в Kubernetes API server. В итоге повышение привилегий сводится к тому, что атакующий с возможностью создавать такие сертификаты для подходящего для его целей пользователя или группы создает сертификат и далее с ним входит в систему - game over!

Необходимо выполнение нескольких условий:
1) Атакующий в RBAC должен иметь права на отправку CSR
2) Атакующий в RBAC должен иметь права на одобрение CSR
3) Атакующий должен правильно выбрать существующего пользователя или группу для которого генерирует сертификат, чтобы он мог что ему надо или поднять привилегии еще дальше (типа через escalate для ClusterRole)

Вот так вот сморишь CSR API не понимаешь его до конца, а оно вон что позволяет вытворять ;)

Немного анонсов 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. Идею со стикерпаком я не забросил и работаю над ним ;)

Крутая серия постов про аутентификацию и авторизацию в Kubernetes:
1) AuthN в Kubernetes
2) AuthZ используя RBAC
3) Поднятие привилегий в обход AuthN и AuthZ
4) Про защиту на базе admission controllers
5) Про защиту на базе на базе Pod Security Policies и Pod Security Admission

Отдельно отмечу третью статью из цикла под названием "From dev to admin: an easy Kubernetes privilege escalation you should be aware of — the attack". Там рассказывается как можно поднять свои привилегии в кластере, получив доступ к сертификатам на Nodes. По сути это тот же сценарий, что мы рассматривали недавно в посте про CSR API, с тем отличием что мы не через API это делаем, а непосредственно ручками все подписываем.

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

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

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

В прошлую пятницу проводил вебинар "Методично закрываем вопросы безопасности в 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], если еще не ответили, то время еще есть - это важно для понимания состояния нашего сообщества и индустрии.

Stratus Red Team - это Atomic Red Team, но только для Cloud.

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

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

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

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

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

Security through understanding/observability.

Участник 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.

Презентация "Kubernetes RBAC 101" одна из самых понятных, наглядных и полных на тему AuthN и AuthZ в Kubernetes на мой взгляд.

Рассматриваются механизмы AuthN:
- X509 Client Certs
- Bearer token
- HTTP Basic auth
- Auth proxy
- Impersonate

Все это идет с примерами схем и команд.

Рассматриваются механизмы AuthZ:
- Node
- ABAC
- RBAC
- WebHook
- AlwaysDeny и AlwaysAllow