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

Недавно один мой товарищ спросил: а как посмотреть все встроенные Kubernetes Roles (те, что используются в RBAC)?

И я задумался как же действительно встроенные/стандартные Roles попадают в кластер и решил разобраться с этим вопросом. В итоге, все они вшиты в код (вот так это выглядит для версии 1.24) и никаких отдельно, лежащих или встроенных YAML!

Можно посравнивать файл "plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy.go" из разных версий и обнаружить что, от версии к версии он периодически претерпевает изменения, так что встроенные Roles не статичны, а порой изменяются.

На правах владельца канала позволю себе небольшую вольность в эту пятницу и рад сообщить, что наша молодая, небольшая команда Luntry из Санкт-Петербурга начинает потихоньку расширяться и искать новых коллег, единомышленников для развития нашего продукта! Если вам или вашим друзьям/знакомым интересная тема security и observability в современных микросервисных инфраструктурах, то это определенно к нам ;)

Мы в поисках:
- Go разработчиков
- Инженера техподдержки
- Frontend-разработчика (React.js)
- QA инженера (Python)
- С\С++\Rust разработчика

Мы работаем с: PostgreSQL, Linux, Kubernetes, eBPF, HighLoad и нетривиальными задачами.

Сами вакансии еще пока нигде не опубликованы - есть возможность откликнуться напрямую (@Qu3b3c или de@luntry.ru). Готовы рассмотреть специалистов разного уровня, главное чтобы нам было вместе по пути. ЗП по результатам собеседования.

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

Давненько я ничего не рекомендовал на посмотреть. Исправляюсь!

Стали доступны слайды и видео с SREcon22 Americas. Как написано в описании данного канала:"Ценим и любим reliability и security, а также observability." Поэтому я не разделяю надежность и безопасность, то и то сильно взаимосвязаны.

В программе конференции много интересного о Observability, Security, eBPF, Distributed Tracing и т.д.

В превью вы видите слайд из одного из докладов. Какого?! Думаю, тем кому интересно найдут самостоятельно ;)

CNCF Security Technical Advisory Group подошла к финальной стадии подготовки Cloud Native Security Controls Catalog, который представляет из себя как не трудно догадаться из названия перечень контролей и базируется на двух документах: Cloud Native Security Whitepaper (CNSWP) и Software Supply Chain Best Practices (SSCSP).

Весь процесс состоял из двух фаз - подробнее о них тут (1,2) и сейчас до 11 мая идет голосование, получение feedback. Также уже готов мапинг пунктов этого каталога на NIST SSDF (Secure Software Development Framework), а в будущем планируется и на CSA, FedRamp, SOX, GDPR и другие стандарты. А еще планируется перевод всего в машино читаемый формат (OSCAL, JSON и т.д.), а не как сейчас Excel табличка =)

Вчера с коллегами игрались с разными сканерами образов, что работают в Runtime. То есть реализованы как Kubernetes operator, начинают сканировать при deploy и никак не интегрируются с CI и ImageRegistry. Оказалось что у многих из них есть достаточно досадные пробелы/проблемы в работе:
1) Сканируются не все images из Kubernetes ресурса, а только первый
2) Сканируются не все типы containers: Containers, initContainers, ephemeralContainers и пропускаются образы (напоминает это)
3) Сканируют не все images, так как получают их не из Pods, а из вышестоящих сущностей и пропускают, то что добавляется через MutatingAdmissionWebhook (типа istio или vault)

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

Любопытная статья "Compromising Read-Only Containers with Fileless Malware", где авторы показываются, что это не останавливает злоумышленников с Fileless Malware.

Делая файловую систему невозможной для изменения, злоумышленник не может записать исполняемый файл своего вредоносного ПО на диск. Большинство атак основаны на записи файлов, но атакующий может и использовать Fileless Malware как часть своей атаки.

Для демонстрации было взято следующее окружение:
- Redis как таргет
- coreutils как часть образа Redis
- CVE-2022-0543 Redis Lua Sandbox Escape and Remote Code Execution - выполнение любых команд через eval()
- spec:containers:securityContext:readOnlyRootFilesystem:true
- Отсутствие других механизмов безопасности

Для запуска вредоносного кода используется:
- /dev/shm (более известна как tmpfs) - для создания файлов в контейнере с read-only filesystem
- Утилита mktemp из GNU coreutils - для записи в /dev/shm
- DDexec для выполнения Fileless Malware

Моё IMHO - пример хороший, но многое что в нем хорошо подобрано - и тип уязвимости и наличие интерпретатора, и наличие дополнительных утилит в образе и т.д. Ну и само применение Fileless Malware при записи 2-х дополнительных файлов делают атаку не такой уж и fileless ...

В преддверии своего с коллегой выступления на HighLoad++ 2022 с докладом "eBPF в production-условиях" хочу поделится мнением о двух небольших pdf-ках (назвать их книгами язык не поворачивается - обе не более 70 страниц) про eBPF:
1) "What is eBPF?"
2) "Security Observability with eBPF"

Оба документа написаны разработчиками CNI Cilium и хорошо погружают в текущее состояние eBPF, так что свое знакомство с данной технологией можно начать с чтения/изучения данных док.
В обоих документах есть упоминание любопытного проекта Tetragon, но он до сих пор не доступен, но как появится я про него обязательно отдельно напишу.

P.S. Буду рад лично познакомиться и пообщаться на HighLoad, а также показать наш Luntry - у нас будет свой стенд =)