Разграничение прав доступа к ресурсам в Kubernetes решается с помощью Role-Based Access Control (RBAC), который пришел на смену Attribute-Based Access Сontrol (ABAC). Данный подход достаточно прост и крутиться вокруг: Role, ClusterRole, RoleBinding и ClusterRoleBinding. В ролях описывается с какими ресурсами что можно делать. В биндингах описывается каким субъектам (users, groups или service accounts) какие роли даны. Но, как и в любом вопросе всегда есть свои нюансы ... дьявол, как говорится, кроется в деталях. Далее рассмотрим наиболее интересные моменты.

Безопасность Helm 3. В конце 2019 года под эгидой CNCF проводился 3rd party security audit для Helm 3.0.0 (dev-v3 branch) (На момент написания актуальная версия уже 3.2.0). Весь аудит состоял из двух фаз:
1) Общие проверки состояния безопасности
2) Ручной аудит кода

Самое важное/интересное в первой фазе это сравнение с Helm2: серверный компонент Thiller убрали и контроль доступа теперь на самом Kubernetes, что естественно уменьшает attack surface.

О второй фазе сами аудиторы говорят так "The goal was not to reach an extensive coverage but to gain an impression about the quality.". Так что сразу можно не рассчитывать на обилие найденных проблем. Была найдена всего одна проблема "HLM-01-001 Packaging: Denial-of-Service via Symbolic Links " с низким уровнем критичности (CVE-2019-18658). Примечательно что данная проблема актуальна и для Helm 2, что говорит о заимствованном коде. Так все достаточно хорошо при условии, что атакующий не имеет доступа к системе, на которой работает Helm 3, в противном случае можно

Не важными для безопасности на первый взгляд `LimitRange` и `ResourceQuota` только такими кажутся. Они играют важную роль в жизни Kubernetes кластера, так как без них он может спокойно уходить в DoS (Denial of Services). Это может быть из-за исчерпания ресурсов:
- через чрезвычайно прожорливые активные сущности. По умолчанию контейнеры никак не ограничены в ресурсах!
- через количественные показатели. По умолчанию нет никаких ограничений на количество ресурсов Kubernetes (Deployments, Pods, Services, Jobs и т.д.)

Первую проблему решает LimitRange. Он накладывает ограничения по ресурсам (cpu, memory) на контейнеры, поды и PVC в namespace. В нем описываются запросы по умолчанию, минимальные и максимальные.

Вторую проблему призвана решать ResourceQuota. Она накладывает ограничения, которые ограничивают совокупное потребление ресурсов для данного namespace. В нем описываются лимиты по ресурсам (тут имеем отличную связку с LimitRange) для данного namespace и количество объектов, которые может быть создано в данном namespace. Речь почти о всех стандартных ресурсах и CRD.

Хорошие примеры по теме можно найти в выступлении "Заделываем дыры в кластере Kubernetes".

Возможно, вы не знали, но kubectl из коробки поддерживает расширение через плагины. Это очень удобная возможность расширять kubectl и делать сложные вещи очень быстро и просто, а потом это и переиспользовать. Также для этого даже есть менеджер плагинов - Krew. В каталоге уже более 90 плагинов. Там есть как те, что просто делают удобный вывод, так и те, что за команду выполняют ряд сложных действий. Нам больше всего интересны те что связанны с безопасностью и тут их тоже предостаточно. Работа с RBAC: access-matrix, rbac-lookup, rbac-view, rolesum, who-can. Подготовки PSP - advise-psp. Управление профилями AppArmor - apparmor-manager. Проверка ресурсов Kubernetes с точки зрения безопасности - kubesec-scan, score. Поиск используемых устаревших image (с прицелом на наличие 1day уязвимостей) - outdated. Также ряд из плагинов отлично подходят и для пентестов, типа net-forward, что позволяет проксировать произвольный TCP сервис в кластере. И много еще всего полезного – обратите внимание и начните использовать ;)

Одной из больших проблем больших систем с их моделями прав доступа, разращениями и т.д. является переизбыток прав у субъектов (пользователей, групп, сервис аккаунтов). Чаще всего это связано с тем, что кто-то попросил права что-то сделать, доделать, исправить. А после этого данные права так и остаются у пользователя. А со временем этот снежный ком все растет. После чего данные такого пользователя компрометируются, и злоумышленник как раз благодаря тем правам "дай мне на права роли N на несколько минут" и успешно продвигается в системе. Такое можно встретить и в SAP, Oracle и т.д. и Kubernetes не исключение. Полностью исключить такие сценарии ("дай мне права на время") в реальном мире врят ли можно (Хотя, можно закопать все в бюрократической рутине, чтобы было невозможно работать). Что делать? Своевременно забирать те права что не требуются для повседневных задач вашим коллегам. Для Kubernetes можно воспользоваться таким проектом как kube-janitor. Он делает одну простую вещь - удаляет ресурсы (а те же RoleBinding, ClusterRoleBinding это тоже ресурсы) в соответствии с установленным TTL (Time To Live) или датой истечения срока (expiry date). Так что данный проект может позволить не забыть забрать права, которые были даны на время. Добавив еще к проекту своевременное оповещение/напоминание до непосредственно удаления сделало бы kube-janitor еще удобнее. Весь код на python доступен, так что добавить такую возможность не проблема.

Пример:
kubectl annotate rolebinding TempRepairBinding janitor/ttl=1h

Если вам интересно следить (а возможно и принимать участие) во встречах CNCF Special Interest Group on Security, где обсуждают secure access, policy control, privacy, auditing, explainability и многое другое, то за встречами и результатами можно следить в этом Google документе.

RBAC.dev - это проект/сайт на котором собраны различные материалы связанные с Kubernetes RBAC. Естественно все это призвано помочь правильно внедрить и поддерживать RBAC в кластере. Среди материалов можно найти:
- ссылки на официальную документацию
- сторонние статьи и выступления
- инструменты для анализа, работы и визуализации

Отдельно можно выделить и recipes.rbac.dev , где собраны полезные снипеты и команды.

Network Policies - определяет какие Pods и Endpoints могут взаимодействовать по сети друг с другом (такой кластерный firewall). Это очень важная с точки зрения безопасности сущность, которая позволяет реализовать концепцию микросегментации. Сразу стоит учесть, что в Kubernetes есть поддержка (начиная с 1.6), а реализация лежит на CNI плагинах. Забавно что в любом случае можно применить политику, только она не будет действовать если нет поддержки.
По умолчанию, любой Pod не изолирован на получение и отправку данных. В политике можно описать правила как для входящего (ingress), так и исходящего (egress) трафика - работает это по принципу whitelist.
Определенную сложность в чтение политик вносит возможность не объявлять, оставлять пустыми некоторые поля, типа: namespace, PodSelector, policyTypes, что по разному будет влиять в случае ingress и egress трафика.
Для старта можно взять Kubernetes Network Policy Recipes.

Kubernetes Distributions & Platforms - Google документ, описывающий, где какие версии Kubernetes используются и поддерживаются. Может быть полезно, как и при выборе, так и при анализе безопасности, пентесте - поможет определится какие фичи уже есть и в какой стадии, а каких еще даже нет. От версии к версии Kubernetes делает приличные изменения.

Cloud Matrix - MITRE ATT&CK Matrix покрывающая cloud-based techniques. Есть обобщенная, так и специализорованная марица для платформ: AWS, GCP, Azure, Azure AD, Office 365, SaaS. Отличный старт для того чтобы понимать что и где атакующий может делать. Естественно из того что публично встречалось и известно, как и любая матрица MITRE ATT&CK здесь только известные техники.

Небольшая инструкция о том, как только с помощью curl при попадании на Pod, используя его service account, можно обращаться к Kubernetes API. Это очень сильно пригодится при дальнейшей разведке и атаки.

От версии к версии Kubernetes может менять API и меняется такое поле как apiVersion. Оно бывает в стадиях alpha, beta и stable или также известное как General Availability (GA). Также может быть и разная группа: apps, batch, policy, rbac.authorization.k8s.io, certificates.k8s.io и т.д. Что у вас в кластере есть можно посмотреть с помощью kubectl команды api-versions.

Или вот таким curl запросом из Pod даже при наличии только default service account:
curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/apis

Вы получите о том какие версии API используются, включая CRD. Данные о CRD могут дать информацию о том какие сторонние решения используются и возможно использовать их для атаки. Так, например, можно знать какие порты точно слушаются сторонним решением. Также точная информация о apiVersion позволит правильно составлять запросы к тем или иным ресурсам в соответствующей версии Kubernetes, а не перебирать вслепую.

Некоторое время назад мы рассматривали как использовать curl, для общения с Kubernetes API. Сейчас рассмотрим тот же сценарий, но только с применением kubectl. Это позволит использовать как всю мощь kubectl, так и его плагинов (не забываем о krew). Команда выглядит следующим образом:

kubectl --server=https://ip --certificate-authority=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt --token=`cat /var/run/secrets/kubernetes.io/serviceaccount/token` <command>

Скорее всего это будет полезнее если удалось получить доступ к Service Account с широким списком возможностей.

Допустим вам удалось тем или иным способом выбраться из контейнера на Worker Node или просто сразу попасть на Node. Где и что там лежит все самое интересное?
Вспоминая о том, как много всего зависит и крутится вокруг Public Key Infrastructure (PKI) в Kubernetes - вас сразу должна посетить мысль о сертификатах ;)

- Если кластер был развернут с помощью kubeadm, то сертификаты будут внутри директории /etc/kubernetes/pki.
- Если кластер был развернут с помощью kubespray, то сертификаты будут внутри директории /etc/kubernetes/ssl.

Как вы уже догадались путь зависит от того как кластер был развернут - это надо учитывать.

В Kubernetes предусмотрен механизм, позволяющий минимизировать, смягчить последствия в случае компрометации токена Service Account. Достигается это благодаря `ProjectedVolume, с помощью которого можно сделать ротацию токенов для `Service Account, в описании спецификации Pod. Если будете искать в описания Kubernetes API, то там он называется `ServiceAccountTokenProjection. Данный объект имеет поле `expirationSeconds в котором задается через какое время kubelet volume plugin должен заменить токен. При это попытки заменить токен начнутся если токен живет уже более 24 часов или прошло более 80% от заданного ему времени жизни. ОЧЕНЬ ВАЖНО, что ваше приложение само отвечает за перезагрузку токена - не забудьте о такой функциональности если собираетесь использовать ротацию токенов. Зато если атакующий заполучил токен, то действовать он у него будет ограниченное количество времени, и он может не успеть сделать задуманное или нервничать, спешить, совершая много ошибок, по которым его можно будет обнаружить.

Сейчас можно много, где встретить о важности, критичности сканирования image контейнеров на уязвимости (на уже известные 1-day уязвимости). Для этого появилось много инструментов - более десятка точно, как коммерческих, так и open source. Они позволяют по версии найти проблемы класса "низко висящие фрукты". При этом версию можно определить не всегда ...

Определенно это хорошая вещь, но по мне очень переоценённая. Большая часть найденных уязвимостей, как показывает практика, принадлежит коду в сторонних библиотеках, который не используется и соответственно не доступен и атакующему. Точно это может знать только разработчик. Далее либо вы добиваетесь "0" предупреждений, либо включаете режим "анализа рисков" и уходите в закат)

Интересная статья "Binary Authorization for Borg: how Google verifies code provenance and implements code identity" из документации Google Cloud, описывающая как у них устроен процесс выкатки и проверки кода/сервиса в production.
В модели угроз тут рассматривается угроза от программного сервиса, который имеет доступ к пользовательским данным. Простыми словами инсайдер способный внедрить вредоносный код в подобный сервис или (не)специально заложить уязвимость.
Документ основывается на том, как они в Google минимизирует подобный сценарий в своей системе Borg (прародитель Kubernetes). В принципе, разбираясь в Kubernetes не составит большого труда это перенести и туда. А в конце есть замечательный раздел "Adopting similar controls in your organization" для этого.
Отдельно хочется отметить “Service-specific policy”, которую нужно создавать под каждый сервис и без чего данный подход работать не будет.