Интересный момент про вчерашний трюк с получением services и портов во всех namespace'ах через CoreDNS. Если попытаться поискать в курсе об этом сами авторы Kubernetes, то данную проблему можно найти в Kubernetes 3rd Party Security Audit - весь список проблем и их состояния можно посмотреть тут (можно отметить, что далеко не все еще закрыто). Но, кажется, оно не отражает реального состояния дел... Вот если зайти в интересующую нас проблему под номером 29 "CoreDNS leaks internal cluster information across namespaces" (наш кейс), то можно увидеть комментарий "According to #81137 (comment), the issue is fixed in CoreDNS v1.6.2 which was released with k8s 1.16, so I think it's safe to say this can be closed". При этом буквально вчера на такой же конфигурации все отлично отработало! Баг в итоге не закрыли или заново переоткрыли ?!

PwnChart для Helm 2. Смысл данного чарта состоит в использовании ClusterRoleBinding, который привязывает к имеющемуся в Pod'е ServiceAccount супер роль cluster-admin. То есть на лицо повышение привилегий в Kubernetes кластере через Helm 2. В чарте можно может быть и другая полезная нагрузка не только ClusterRoleBinding - тут дело только в вашей фантазии. Это возможно в конфигурации helm 2 по умолчанию (отсутствует TLS и X509). Может быть очень полезно например если PodSecurityPolicy, RBAC, NetworkPolicy мешают сделать повышение привилегий, а достучаться до Tiller можно.

Если во время пентеста, вам внутри Pod'а понадобится kubectl, то наиболее не заметно на мой взгляд будет его скачать с помощью curl с https://storage.googleapis.com как и советуют в официальной документации, а не с какого-то стороннего ресурса чье имя в трафике может вызвать подозрение с большей вероятностью.

Разграничение прав доступа к ресурсам в 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.

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