Сегодня поговорим не о security, не о reliability и даже не об observability в Kubernetes.

А поговорим как можно упростить и улучшить жизнь разработчиков в инфраструктурах с Kubernetes (да и не только).

Кто-то может тут сразу поднять вопрос: "Нужно ли разработчику знать Kubernetes?" - об этом у меня был отдельный пост и в рамках нее упоминается статья "Maximizing Developer Effectiveness". Из которой вы и могли уже узнать о таком замечательном проекте от команды Spotify как Backstage.

Backstage это OpenSource портал для разработчиков с системой плагинов, позволяющий обозревать всю информацию о системе в одном месте! И да эта система уже понимает, что такое Kubernetes!


Проект находится в CNCF Sandbox, у него уже более 50 крупных публичных компаний пользователей. Я знаю и российские компании, которые используют данное решение.

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

Прямо online можно поиграть с решением на данном demo стенде.

Дискуссия: Где правильнее (безопаснее) хранить секреты - в переменных окружения или на файловой системе?

В статье "Stop Storing Secrets In Environment Variables!" автор достаточно эмоционально отстаивает свою точку зрения на этот счет) Его фаворитом тут является использование ephemeral filesystem mounts.

А какая ваша позиция на этот счет и что говорит ваш опыт работы с секретами?

Компания Google в своем Security Blog сообщила: "Until December 31 2022 we will pay 20,000 to 91,337 USD for exploits of vulnerabilities in the Linux Kernel, Kubernetes, GKE or kCTF that are exploitable on our test lab."


Максимальное вознаграждение за эксплоит теперь составляет 91,337$, при этом вознаграждение есть и за 1day и за дубликаты с уникальными техниками эксплуатации!

Напомню, что в 2020 году компания Google (родитель Kubernetes) расширила свою Vulnerability Rewards Program (VRP), добавив туда Kubernetes-based инфраструктуру под названием kCTF.

О парочке таких публичных успешных вознаграждений я уже писал [1,2].

Мне кажется, что это очень хорошо показывает, насколько Google внимательно относится к Kubernetes и какую ставку на него делает.

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

В связи с ростом сложности и запутанности систем, на первый план выходит observability. А то мало ли на чем там у вас это все держится ;)

Это как надежности, так и безопасности системы касается.

Всем хорошей пятницы и выходных!

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

В статье "eBPF for Service Mesh? Yes, but Envoy Proxy is here to stay" мне понравилось как рассматривается текущая картина в сравнении да еще и с учетом технологии eBPF. В итоге рассматривается 4 архитектуры:

1) Sidecar proxy (service proxy)
2) Shared proxy per node
3) Shared proxy per service account (per node)
4) Shared remote proxy with micro proxy

Все это при этом сравнивается по 4 пунктам:
- Memory/CPU overhead
- Feature isolation
- Security granularity
- Upgrade impact

И не могу не сказать о статье "How eBPF will solve Service Mesh - Goodbye Sidecars" - там речь о еще одной архитектуре:
5) eBPF Accelerated Per-Node Proxy

2 важные цитаты про eBPF в этом контексте из статей:
1) " this would be quite difficult and may not be the right approach. eBPF is an event-handler model that has some constraints around how it runs."
2) "For some use cases, a proxy is still needed."

Выводы делайте сами с учетом ваших потребностей ;)

Сheckov прекрасный инструмент, который позволяет управлять и анализировать IaC таких платформ как Terraform, Kubernetes, Helm и многих других. Он активно продвигает концепцию Policy-as-code.

Его можно использовать как CLI для сканирований на локальных машинах разработчиков или даже как часть IDE или более обыденно в CI pipelines через GitHub Actions. Но все равно остаётся риск что злоумышленник обойдет эти этапы. И тогда последним бастионом защиты остается Validating Admission Controller!

Проект Whorf это как раз такой контроллер на базе Сheckov.

Мое мнение:
1) Whorf проигрывает любому специализированному Policy Engine для k8s
2) Kyverno и OPA Gatekeeper также умеют в CLI
3) Вы врятли его даже попробуете так как для запуска надо получать API key от вендора

Многие вендоры сегодня пытаются сделать универсальные комбайны, но отлично видно, как они сильно проигрывают специализированным решениям в той или иной области. Все это скорее чтобы закрыть пустоту, а не решить проблему

Всем привет!

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