Сегодня у меня очень знаменательный день! Сегодня исполняется 1 годик моему сынишке и 2 года данному каналу =)

Спасибо всем кто читает, комментирует, спрашивает вопросы и просто интересуется Kubernetes!

И раз уж сегодня я о лично, то расскажу как я заинтересовался информационной безопасностью. Дело было в октябре 2003 и я с накопленными деньгами шел в Роспечать, чтобы купить журнал "Игромания", но после получасового мучения перед витриной, я вернулся домой со спец выпуском журнала "Хакер" (диск с того выпуска вы видите выше). Конечно, после его прочтения я вообще мало что понял (да и следующие несколько выпусков тоже), но мне очень хотелось в этом разобраться и я начал разбираться в теме. А в последствии мне довелось побывать и автором статей и редактором рубрик в журнале, но тогда о таком я даже и не мог подумать)

Все начинается с малого и дальше при желании и упорстве начинает расти и развиваться ;)

Презентация "SLSA in the Kubernetes Release Process" расскажет, как обстоят дела у Kubernetes с безопасностью Supply-chain на март 2022. И если вы задаетесь вопросами:
- На сколько в его релизах хорошо или плохо с этим?
- Можно ли внедрить туда вредоносный код?
- Можно ли подсунуть что-то в сборку?

То данная преза все расставит по своим местам! Я лишь напомню, что:
1) SLSA (”salsa”) расшифровывается как Supply-chain Levels for Software Artifacts.
2) С версии 1.23 Kubernetes соответствует SLSA Level 1

При этом это будет очень полезно изучить в преддверии вебинара «Обеспечение безопасности в текущих условиях: что делать с opensource», который состоится сегодня в 19.00 (Мск), и в котором я приму участие ;)

Недавно компания SUSE выложила в открытый доступ решение NeuVector для безопасности контейнеров. За это время несколько читателей попросило рассказать, что я думаю о данном инструменте.

О том что умеет данная платформа я рассказывать не буду - с этим можно познакомиться в документации, а поделюсь с вами своим мнением о некоторых концептуальных моментах и моментах реализации для Kubernetes.

1) Для обеспечения безопасности workloads создана новая/собственная абстракция - Groups. Приложения, базирующие на образе с одним именем, попадают в одну группы и как следствие может быть каша и нет никаких Deployment, DaemonSet и т.д.
2) Сетевая карта взаимодействия строится для Group, а не для workloads и это касается всего.
3) Для сканирования образов на уязвимости создан свой сканер — это не Trivy/Clair/Anchore/Grype и по его качеству сложно что-то сказать.
4) Создан свой собственный Admission Controls со своим языком описания правил/политик - использовать знания популярных PolicyEngines (kyverno/gatekeeper) не получится и при этом можно писать правила только для определённых 9 типов k8s ресурсов.
5) Для контроля сетевой активности созданы свои собственные Network Rules. Этот инструмент не понимает NetworkPolicy от CNI Kubernetes со всеми вытекающими.
6) Для отслеживания сетевой активности используется собственный DPI - с соответствующими оверхедами на сеть ...
7) Для отслеживания процессов и взаимодействия с файловой системой используются inotify и fanotify - по производительности, естественно, проигрывают eBPF.
8) Понравилось стремление к концепции Security-As-Code через Custom ресурсы: NvSecurityRule, NvClusterSecurityRule, NvCrdAdmCtrlSecurityRule, NvWafSecurityRule, но использовать их совсем не обязательно ...

Инструмент умеет много чего, но все как-то очень странно реализует и достигает IMHO, как будто цель была реализовать так как никто не делает)

P.S. В комментариях можно пообсуждать данный проект подробнее.

Отличный репозитарий на тему ресурса NetworkPolicy в Kubernetes!

В нем много всего полезного по теме и особенно для тех кто только знакомится с этим механизмом, который по сути из себя представляет родной межсетевой экран для Kubernetes!

Если вы хотите как-то ограничить сетевое взаимодействие, но не знаете как к этому поступится, то уделите немного времени для знакомства с данным ресурсом ;)

Есть и хороший пошаговый tutorial по созданию NetworkPolicy и полезные инструменты для ручного их создания.

У нас же в Лантри мы пришли к полностью автоматической генерации NetworkPolicy как native формата так и custom для Calico и Cilium, так как в ручную копаться с labels от workloads и namespaces, то еще веселье =)

Буквально вчера вышел замечательный 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). Но отмечу, что все это так или иначе частные случаи и при более продвинутом атакующем, обойти это будет не сложно.