Если вы абсолютно не знаете, как подступится к безопасности своего приложению на базе микро сервисов, то можно начать с «OWASP Сheat Sheet Series. Microservices-based security architecture documentation» и для этого будет достаточно взять листок бумаги с ручкой или excel табличку + пообщаться с вашей командой разработки. Данный Сheat Sheet естественно подходит и при использовании Kubernetes. Основная суть/соль — это инвентаризация, описание, выстраивание связей и поддержка актуальности ваших знаний о системе. Можно об этом посмотреть и в видео.

Возможные модели нарушителей для Kubernetes (взято из ранее уже упомянутого стороннего аудита безопасности платформы). В принципе, тут со всеми все ясно кроме если только последнего действующего лица в этом списке - "End user". Его туда добавили, так как некоторые атаки могут проходить через обычных пользователей приложений, что хостятся в кластере (например, Cross-Site Request Forgery (CSRF)). И как вы понимаете это в первую очередь проблема безопасности приложения что там хостится, а не самого Kubernetes. Но все равно такой сценарий атаки через одно звено (через пользователя), а далее уже и на сам Kubernetes возможен.

Везде пишут, что для хранения критичной информации используйте Secrets, вместо ConfigMaps. Но она все равно хранится в открытом виде, так как не настроено шифрование. Важно знать следующее:
1) Необходимо использовать `EncryptionProviderConfiguration` (появился с Kubernetes 1.7)
2) Необходимо создать конфиг файл и передать его через --encryption-provider-config аргумент kube-apiserver - он отвечает за шифрование и дешифрование данных
3) Можно задавать какие ресурсы вы хотите шифровать (не только Secrets)
3) Есть поддержка 3 типов шифрования: aescbc, secretbox и aesgcm (все симметричное)
4) Ключи шифрования хранятся на диске всех api-servers нод, если вы не используете Key Management Service (KMS)
5) Ключи шифрования можно и нужно ратировать

На скриншоте вы видите возможности атакующего до использования шифрования данных в etcd и после их шифрования с использованием KMS.

Что нужно подготовить заранее при пентесте/аудите Kubernetes инфраструктуры?

Конечно же, специального подготовленный image с кучей хакерских/пентестерских и просто Kubernetes, container - specific инструментов. Если у вас есть возможность запустить свой Pod, со своим image, то стоит его заранее подготовить и выложить, для последующей выкачки и установки. Так что делайте его заранее и в качестве ориентира могу вам посоветовать проект - botty. Внутри есть kubectl, krew c плагинами, botb, peirate, gcloud, istioctl, amicontained, dive, linuxprivchecker.py, conmachi, helm2, и много еще чего полезного (curl, dnsutils, nmap, ...). Постепенно мы пройдемся по каждому инструменту в отдельности. При этом данную сборку еще явно есть чем дополнить

Также понадобится и специально подготовленное YAML описание для Pod'а, в котором будет работать image. Оно может помочь сделать побег из контейнера (зависит от наличия и настроек PodSecurityPolicy). Об этом также поговорим отдельно.

Автор Kubernetes Easter CTF, о котором я писал ранее, выложил весь исходный код и ресурсы, используемые в контесте. Можно посмотреть, где были спрятаны все 9 флагов, как вообще был устроен контест и взять его за основу для организации собственного. А кто не успел может его развернуть для себя и попробовать пройти самостоятельно.

Классный трюк, который может пригодиться при пентесте Kubernetes - а именно перечислить все services и порты во всех namespace'ах.

$ dig SRV +short any.svc.cluster.local
0 7 8888 10-244-100-5.node.demo.svc.cluster.local.
0 7 8888 10-244-85-199.node.demo.svc.cluster.local.
0 7 8888 10-244-85-201.node.demo.svc.cluster.local.
0 7 443 kubernetes.default.svc.cluster.local.
0 7 53 kube-dns.kube-system.svc.cluster.local.
0 7 9153 kube-dns.kube-system.svc.cluster.local.
0 7 80 nginx-webui.demo.svc.cluster.local.
0 7 6379 10-244-85-200.redis.demo.svc.cluster.local.

Из минусов это то, что нужна утилита dig из пакета dnsutils, но ее можно принести в контейнер потом.
Точно работает при дефолтно настроенном CoreDNS.

Интересный момент про вчерашний трюк с получением 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 документе.