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

В прошлую пятницу аж несколько человек скинуло мне вот эту картинку/ссылку.

Сразу скажу, что участие в подготовке данного документа я не принимал и читать его мне не доводилось (пока он доступен только ограниченному кругу лиц).

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

Сразу в глаза бросается (помимо неочевидных формулировок - "изоляция контейнеров") отсутствие в перечне функций безопасности: Runtime Security, Network Security.

Надеюсь что тут также будет учтена специфика оркестраторов (Kubernetes), ведь контейнеры в вакууме мало кому интересны и нужны.

P.S. В комментариях можно обсудить данный слайд и что на ваш взгляд тут не так или не хватает.

P.S.S. У меня с хорошими товарищами и крутыми специалистами по Kubernetes в очень-очень ранней стадии находится проект с кодовым рабочим названием "НИБК", который может составить конкуренцию данному документу ;)

"The Principle of Ephemerality" - очень интересная статья, дающая много пищи для размышлений, относительно того, как подходить к организации процессов и архитектуре системы.

Общий посыл: "Everything that can be ephemeral, should be ephemeral."

В статье есть 6 основных разделов:
1) Lifespan of Ephemerality
2) Ephemeral credentials - OpenID Connect (OIDC), Service Account Token Volume Projection
3) Ephemeral keys - Sigstore’s Fulcio project
4) Ephemeral attestations - Tekton Chains
5) Ephemeral infrastructure - “pets vs. cattle” idea, Knative
6) The attacker perspective

Классно что часть из этих разделов заканчиваются "Homework / Call-to-Action", что является прямым побуждением к действию.

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

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

Оказывается, в Kubernetes помимо штатного kube-scheduler, существует еще официальный` Kubernetes operator под названием descheduler.

Логика данного решения очень проста и базируется на возможности задавать те или иные политики и стратегии, при срабатывании которых Pods, подходящие под нее будут перемещены или выселены с Node.

Поддерживаемые политики и стратегии:
- RemoveDuplicates
- LowNodeUtilization
- HighNodeUtilization
- RemovePodsViolatingInterPodAntiAffinity
- RemovePodsViolatingNodeAffinity
- RemovePodsViolatingNodeTaints
- RemovePodsViolatingTopologySpreadConstraint
- RemovePodsHavingTooManyRestarts
- PodLifeTime
- RemoveFailedPods

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