Немного анонсов 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 - у нас будет свой стенд =)

С выходом Kubernetes 1.24 многие писали о появлении там NetworkPolicyStatus для ресурса NetworkPolicy. И при этом никто внятно не писал что это, для чего, как может быть полезным и как устроено...

Наша команда в преддверии выступления про NetworkPolicy - решили разобраться с этим нововведением не по анонсу, а по реальному запуску Kubernetes 1.24. В результате имеем следующее:
- NetworkPolicyStatus по сути предоставляет единый для всех CNI интерфейс
- По сути это поле status в NetworkPolicy и содержит в себе conditions (поля на скриншоте)
- Скорее всего должен позволить отслеживать ошибки при использовании NetworkPolicy
- Пока ни один CNI туда ничего не пишет

Все в принципе и логично ведь реализация NetworkPolicy лежит на CNI и тут все будет зависеть от конкретной реализации CNI. Если верить данному KEP, то с версии 1.25 вроде как Calico и Cilium начнут использовать это поле, но посмотрим ...