Всем привет!

Напомню что ещё есть возможность купить билеты на ZeroNights 2022 по сниженной/ранней цене и подать свой доклад на конференцию через CFP. Если кто-то сомневается или делает это впервые, то я могу помочь и все подсказать ;)

И конкурс!
В комментариях к этому посту напишите историю из вашей практики или друзей друзей про fails в области ИБ при работе с Kubernetes.

Для затравки я напишу две (согласовано с действующими лицами) вне конкурса!

3 наиболее интересные на мой взгляд истории получат билеты на ZeroNights 2022!

Победителей объявлю 28 февраля ;)

Проект vulnerability-operator это логическое продолжение проекта sbom-operator, от того же автора. Если sbom-operator отвечает за формирование SBOM, то vulnerability-operator берет результаты первого и по расписанию сканирует его на известные уязвимости сканером Grype.

На текущий момент данный оператор берет SBOM из git-repository сканирует его и результат отдает в JSON-file через endpoint и/или как Prometheus метрики.

С автором я обсудил еще один вариант совместной работы этих операторов, и он его уже занес в планы. А именно такой:
1) sbom-operator создает результат своей работы в виде ресурса PolicyReport и связывает его по ownerReference с микросервисом (по аналогии как это делает Starboard-operator).
2) vulnerability-operator реагирует на появление нового PolicyReport и переодически его сканирует и обновляет информацией о известных уязвимостях.

В итоге это позволит полностью реализовать Kubernetes Resource Model (KRM), в которой всегда все о системе можно узнать из YAML ресурса =)

Kubernetes Security SIG и Policy WG зарелизили новый документ, который касается вопроса контроля автоматизации, так и безопасности происходящего в кластере, под названием "Kubernetes Policy Management Paper".

По сути это набор best practices для управления конфигурациями Kubernetes, используя политики (привет Policy Engines!). Документ освещает два момента:
1) Какие проблемы Kubernetes политики могут помочь решить
2) Как Kubernetes политики могут быть реализованы

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

Без внимания не остается Runtime политики, покрывающие происходящие уже внутри контейнеров и дополняющие Policy engines.

Документ MUST READ для всех. Без подобного построить грамотную безопасность в K8s невозможно на мой скромный взгляд.

Для некоторых может быть новостью, но

kubeclt -n <namespace> get all - не работает!

То есть вы получите не полную - не правильную картину. И при этом это совсем не новость и не сенсация в Kubernetes сообществе — это уже неоднократно обсуждалось [1,2].

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

Одним из решений проблемы может быть krew плагин для kubectl под названием ketall/get-all.

За более детальным погружением в проблему и другими возможными решениями рекомендую обратиться к моему выступлению "Kubernetes Resource Model (KRM): Everything-as-Code"

В продолжении вчерашнего поста поделюсь еще одним нюансом работы с Kubernetes при этом на прямую затрагивающим вчерашнюю задачу получения всех ресурсов из Namespace.

И так, знайте когда вы делаете запрос к Kubernetes API по любому из ресурсов, то в ответ вы получаете всегда целый/полный YAML данного ресурса со всеми вытекающими, а не просто несколько строк. Тоесть в попытке получить список всех ресурсов в конкретном Namespace в ответе к вам придет все их содержимое и если там, на пример, сотни Pods, то придет вся информация о них, аналогично и про все другие ресурсы. Так что, имейте ввиду, что такими запросами можно не плохо так нагружать Kubernetes API.

P.S. Один из старых постов про verbosity в kubectl.

Сегодня опять расскажу о том, что Kubernetes (пока еще) не умеет, но на это уже заведен KEP: "In-place Update of Pod Resources", в ожидании которого большое количество Ops специалистов (для Sec это будет также полезно знать).

Основной смысл данного улучшения заключается в том, чтобы можно было обновлять Pod resource requests и limits вовремя работы без перезапуска Pod или его Containers. По-другому это еще могут называть как Vertical Resources Scaling.

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

Насколько я знаю прародитель нашего герой - Borg подобное умеет.

В комментариях можете поделится какие KEP или просто фичи вы ждете или вам бы очень хотелось видеть в Kubernetes.

Статья "Kubernetes and HostPath, a Love-Hate Relationship" это попытка разобраться в сути уязвимостей связанных с HostPath. Авторы рассматривают 3 уязвимости, позволяющие получить доступ к хостовой файловой системе пользователям без соответствующих прав:
- CVE-2017-1002101
- CVE-2021-30465
- CVE-2021-25741

В итоге все 3 уязвимости одной природы и тесно связаны друг с другом и крутятся вокруг (помимо HostPath) symlink race, TOCTOU.

Предполагаю, что подобное мы еще увидим в будущем.

В статье "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 (Мск), и в котором я приму участие ;)