Если вам нечем заняться на самоизоляции или просто на выходных, то есть прекрасная возможность и время интересно провести и с Kubernetes поиграться на Mini Kubernetes Easter CTF (базируется на AWS EKS). Образы контейнеров доступны на DockerHub. Для участия просто вводите команды в поле “Command” на сайте, так что берете и вбиваете kubectl и понеслась!

Если вы абсолютно не знаете, как подступится к безопасности своего приложению на базе микро сервисов, то можно начать с «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, в противном случае можно