В статье "Privilege Escalation from Node/Proxy Rights in Kubernetes RBAC" авторы разбирают на части права Node/Proxy.

Node proxy позволяет получить доступ к workload через API server, что может быть полезно для troubleshooting и monitoring этого самого workload без предоставления к нему прямого сетевого доступа. По идеи этот доступ ограничен адресом Pod и service IP, но на деле это не так и можно обойти и обратиться к произвольному внешнему адресу. Также пользователи с правами node/proxy могут обратиться к службе, запущенной на Node, а именно Kubelet API и делать/выполнять все что она может, включая выполнение команд внутри Pods! А можно вообще не запариваться с такой замысловатой схемой и с этими права на прямую (в обход API server) обратиться к Kubelet API! И это означает обход Audit Log и Kubernetes admission controls (те же Policy Engines)!

Как итог, контролируйте свой RBAC!

P.S. Уже дописав эту заметку, я понял, что этот момент я недавно освещал, но на базе другой заметки, немного под другим углом.

Hierarchical Namespace Controller (HNC) – контроллер, который помогает реализовать Multi-Tenancy в концепции Namespaces-as-a-Service в Kubernetes.

По умолчанию HNC распространяет (propagates) только RBAC Roles и RoleBindings, но может любой Kubernetes resource: NetworkPolicy, Limit Ranges, ResourceQuotas и т.д.

HNC позволяет организовать namespaces в деревья и применять к этим деревьям те или иные ресурсы. Этот контроллер гарантирует, что эти копии всегда будут синхронизированы с исходной копией. Когда исходный объект обновляется или удаляется, все распространенные копии также обновляются или удаляются.

Это подходит для:
- Fine-grained namespaces
- Self-service namespaces

Рекомендую посмотреть также мини доклад «Namespaces-as-a-Service with HNC and Kyverno», в котором предлагают все это чуть ли не довести до состояния namespace-per-microservice.

Год назад я писал про GKE Autopilot и эта тема не могла не привлечь внимания исследователей. Из статьи "Container Escape to Shadow Admin: GKE Autopilot Vulnerabilities" вы можете узнать, как в таком "суперзащищенном" кластере ограниченный пользователь с возможности создавать Pods, может скомпрометировать Node (запускать там что), затем поднять свои привилегии до кластерного админа и установить invisible и persistent backdoor!

Сценарий:
- Обход OPA Gatekeeper, прикинувшись разращённым Datadog агентом
- Побег с Pods на Node через смонтированный containerd socket
- Поднятие привилегий через service account token найденный на Node и создание shadow administrators
- Установка backdoor через вредоносный mutating admission webhooks

Выводы:
1) Использование Policy Engine не гарантирует вам, что ваши политики правильные и полноценные
2) Сокрытие части информации от пользователя (создание ему слепых зон) может также играть на руку и для атакующего, скрывающего свою вредоносную активность

Некоторое время назад с подачи одного из постоянных читателей данного канала, мы с командой значительно пересмотрели анализ Kubernetes RBAC в нашем решении Лантри для Kubernetes. И вот закончив данную функциональность, хочу поделится своими мыслями/наблюдениями по анализу RBAC (многое понимаешь, когда долго и упорно копаешь в одну сторону).

По итогу, было выделено 3 направления анализа:
1) По Subject (ServiceАccount, User, Group) - какими правами обладает тот или иной субъект.
2) По Permission - какие субъекты имеет то или иное право.
3) По Roles/ClusterRole - какие субъекты разделают между собой ту или иную роль.

Таким образом, это покрывает все возможные задачи по анализу прав субъектов в Kubernetes. А если по вашему мнению нет, то предложите свои варианты в комментариях.

Еще, конечно, к этому для managed Kubernetes можно добавить и анализ annotations у ServiceАccount, которые присоединяют cloud providers о своих IAM сущностях, но это уже другая история (следующий шаг) ...

При проверке podSpec не забывайте, что теперь требуется проверить 3 типа контейнеров (а не 2 как раньше):

1) containers
2) initContainers
3) ephemeralContainers

Ephemeral Containers с 1.18 в Alpha, а с 1.23 перешли в Beta и включены по умолчанию. И не проверяя эту часть YAML, атакующий может обойти проверки вашего PolicyEngine!

Кто как с этим справляется?

- У OPA Gatekeeper в его библиотеке правил нет ни одного правила проверяющего эту часть YAML (но сам он в курсе о них);
- У Kyverno ситуация куда лучше - не зря они себя позиционируют как Kubernetes-native;
- У родного Pod Security Admission тоже все с этим в порядке (его код на скрине);
- У самописных Admission Controllers все в ваших руках).

Будде внимательны ;)

Большинство программных сред предполагают (включая Kubernetes), что у них есть доступ в сеть интернет, но не все и есть те, которым туда путь закрыт (финансовый, государственный сектор и т.д.). Но на эти системы нужно и ставить ПО, и обновлять, и сопровождать его и т.д. Тоесть они должны жить также как и те, что имеют доступ к сети интернет.


Проект Zarf призван помочь облегчить доставку любых программ до таких Air Gap Systems. Данный инструмент позволяет собрать все необходимое из интернет в единый package и затем его установить в изолированном окружении! Сами авторы позиционируют проект как DevSecOps для изолированных систем.

Изучая безопасность Kubernetes, особенно в части PodSecurityContext и SecurityContext, вы наверняка обращали внимание на упоминание там подсистем безопасности SeLinux и AppArmor. Kubernetes понимает их и позволяет использовать их для повышения уровня безопасности в вопросе prevention. НО стоит учитывать, что есть его собственная специфика при их использовании.

Два очень важных момента:
1) Нельзя использовать их одновременно - либо один, либо второй.
2) AppArmor профиль описывает что может и не может происходить внутри опредленного контейнера внутри Pod, а SeLinux профиль описывает только то как контейнерный процесс может взаимодействовать с хостовой ОС. Тоесть SeLinux никак не ограничивает, то что может происходит в контейнерах!

В комментариях можете поделится своим опытом работы с этими решениями в Kubernetes.

CVE-2022-0811: cri-o: Arbitrary code execution in cri-o via abusing “kernel.core_pattern” kernel parameter

Уязвимость в CRI-O container runtime позволяет пользователям, которые могут создавать в кластере Kubernetes произвольные Pods, совершить container escape и получить root доступ на host. Эксплоит назвали "cr8escape".

Уязвимость появилась в 1.19 и была закрыта в последних версиях. Сам CRI-O используется как container runtime по умолчанию в OpenShift и Oracle Container Engine for Kubernetes. Но есть и облачные провайдеры, которые его тоже используются.

Если у вас нет возможности быстро обновиться, то на Policy Engines вы можете запрещать [1,2] создание Pods у которых в sysctl value используется знак "+".

По идее разрешено из контейнера менять только определённые, безопасные параметры ядра, а к остальным доступ запрещен. А вот тут CRI-O ввел ошибку, которая позволяет злоумышленникам обходить эти меры безопасности и устанавливать любые параметры ядра без их проверки.

CVE-2022-26316: TOCTOU issue that could lead to rule bypass

Уязвимость в Falco класса TOCTOU, которая приводит к обходу его правил детектирования. “Исправление” с версии 0.31.1.

Суть проблемы: Falco извлекает некоторые аргументы, читая буферы пользовательского пространства при выходе из системного вызова. А атакующий может изменять аргументы в своем собственном адресном пространстве после системного вызова и до завершения его выполнения.

НО ...

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

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

В статье "Kubernetes Workload Identity with AKS" рассказывается как Microsoft в своем managed Kubernetes решает вопрос к каким облачным сервисам тот или иной Pod имеет доступ, а к каким нет. В своих прошлых постах я рассматривал кейсы AWS на базе их механизма IRSA и Google на базе Workload Identity и вот теперь очередь Microsoft. И если первые два более похожи между собой и пошли по пути ServiceAccount annotation, то тут некоторое время назад был совсем другой путь через AAD Pod Identity ...

Но ему на смену пришел другой механизм Azure AD Workload Identity, который работает можно сказать точно также как и в других облаках - то есть нужно применить соответствующие annotation к ServiceAccount и все. В итоге, все у всех одинаково!

Касаемо российских облачных провайдеров, то такой функциональности пока ни у кого нет - ждем ...

Знаете ли вы что в Kubernetes можно одновременно использовать несколько Ingress controllers?!

Если нет, то знайте, что это возможно благодаря Ingress Class, который можно потом в описание Ingress заявить через ingressClassName.

Это позволит повысить как надежность, так и безопасность ваших кластеров и приложений:
1) Разграничить управление внутренними и внешними приложениями
2) Удобно обслуживать приложения разных типов
3) Уменьшить возможный ущерб (blast radius)

На практике я встречаю компании, которые используют:
- Один Ingress controllers одного вендора, но в нескольких вариациях
- Несколько Ingress controllers разных вендоров, но каждый под конкретную задачу

При этом это, по сути, полная аналогия с Container Runtime (которых в кластере также может быть несколько штук) - там также Runtime Class и runtimeClassName ;)

Собрание всех 3rd party security аудитов под эгидой CNCF.

О данных отчетах я неоднократно писал на канале [1,2,3,4,5,...] и тут они все собраны в одном месте. Может быть полезно для понимание поверхности атаки того или иного проекта, его модели угроз или для проведения собственного исследования.

Сегодня у меня очень знаменательный день! Сегодня исполняется 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 не использовал, а вы?)