От версии к версии 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”, которую нужно создавать под каждый сервис и без чего данный подход работать не будет.

Удобная команда для kubectl чтобы посмотреть, что может делать тот или иной ServiceAccount:

kubectl auth can-i <verb> <resource> --as=system:serviceaccount:<namespace>:<serviceaccountname> [-n <namespace>]

А с помощью аргумента --list можно посмотреть все что разрешено.

У всех крупных Cloud-провайдеров есть свои сервисы предлагающие услуги по безопасности.

- AWS: Security Hub
- GCP: Security Command Center
- Azure: Security Centre

Там они предлагают самые базовые возможности по ИБ. Это полезно знать как при выборе провайдера, так и как источник информации о том, что необходимо иметь/сделать у себя в приватном облаке в направлении безопасности.

Google расширила свою программу Google Vulnerability Rewards Program (VRP). Теперь она покрывает и критичные open-source зависимости Google Kubernetes Engine (GKE).
Это включает privilege escalation уязвимости в hardened GKE lab cluster, который был специально создан для этого - kCTF. kCTF это Kubernetes-based инфраструктура для CTF соревнований. Участникам буден необходимо:
1) Вырваться из контейнерной среды
2) Прочитать один из двух секретных флагов: первый флаг находится в одном Pod, а второй - в другом Pod в другом namespace.
В скоуп входят все ЭКСПЛОТАБЕЛЬНЫЕ уязвимости во всех зависимостях, которые приводят к компрометации Node. Это могут быть privilege escalation уязвимости как в Linux kernel, так и в базовом hardware и в других компонентах инфраструктуры, через которые можно поднять привилегии в GKE cluster.
Можно получить до $10,000 + вознаграждение от CNCF. До этого, Google совместно с CNCF анонсировали bug bounty program для Kubernetes с выплатами до $10,000.

CVE-2020-8555: Half-Blind SSRF в kube-controller-manage

Level: Medium (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N)

Данная Server Side Request Forgery (SSRF) уязвимость позволяет определенным авторизованным пользователям сливать до 500 байт произвольной информации с незащищенных эндпоинтов внутри master хост сети (таких как link-local или loopback сервисов).

Атакующий с разрешением на создание Pod'ов с определеным типом Volume (GlusterFS, Quobyte, StorageFS, ScaleIO) или разрешением на создание StorageClass может заставить kube-controller-manager делать GET или POST запросы (без контроля содержимого тела запроса) из master хост сети по предоставленному пользователем не проверенному URL.

Также сообщается что аутентификационных данный не утекает, то в утекаемых данных может быть что-нибудь интересное.

Если посмотреть патч, то можно увидеть кучу добавленных проверок с комментарием: "don't log error details from client calls in events".

И еще одна недавно закрытая уязвимость по теме Kubernetes!

MitM атаки в уязвимой контейнерной сети в IPv4 only кластере.

CVSS Rating: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:L (6.0 Medium)

Атакующий в подконтрольном контейнере может сформировать специальные ICMPv6 Router Advertisement (RA) сообщения, тем самым перенастроить хост для перенаправления части или всего IPv6 трафика хоста в контролируемый атакующим контейнер. Причина в том что, если даже раньше не было IPv6 трафика и при условии, что DNS возвращает A (IPv4) и AAAA (IPv6) записи, большинство HTTP библиотек будут сначала пытаться подсоединится по IPv6, а затем уже при неудачи переходить к IPv4, тем самым давая возможность атакующему ответить первому и организовать MitM атаку.

Атакующему для проведения такой атаки необходимо находится внутри контейнера с CAP_NET_RAW привилегией (о ней мы и говорили и вчера) в уязвимом окружении. В результате он сможет перехватывать трафик других контейнеров на хосте или самого хоста, где он находится.

Очень неожиданное применение Kubernetes по данным TheRegister.

Исследователи что нашли Half-Blind SSRF в kube-controller-manage (CVE-2020–8555) опубликовали отличное техническое описание как самой уязвимости, так и различные сценарии ее эксплотации. Есть и PoC на базе которого можно уже повторить все сценарии атак, что перечислены в статье:
- Redirecting POST to GET HTTP request trick and sensitive data exposure
- Lan scanning
- CRLF + smuggling HTTP injection in “old” Kubernetes cluster releases

В данном анализе очень хорошо раскрывается момент насколько это критично для облачных провайдеров, что предоставляют managed Kubernetes - там, где за master plane отвечает не клиент, а облачный провайдер.

И в итоге они получили вознаграждение сразу в трех программах: Google VRP, MSRC Bug Bounty (Azure Cloud Bug Bounty) и от Kubernetes через HackerOne.

Сегодня исполняется 6 лет платформе Kubernetes!

"A Survey of Istio’s Network Security Features" - замечательное исследование фич безопасности самой популярной service mesh для Kubernetes.

Авторы на примере своей лабы показывают различные недоработки, ограничения, мисконфиги и подводные камни Istio версии 1.5 (текущая 1.6). В основном они рассматривают:
- IPv6 - специфика работы с ним и ограничения.
- Mutual TLS - способы обхода, мисконфиги.
- Egress restrictions - обходы запрета обращений во внешку.

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

Лично мое мнение что security функциональность у Istio находится на третьих-четвертых ролях и это совсем не security инструмент. Без NetworkPolicy не обойтись в любом случае, а что-то им и так можно решить не прибегая к Istio.

Прежде чем как начинать вносить различные правки, улучшения, хардеринги безопасности в свой Kubernetes кластер. Нужно хорошо понимать, что вообще происходит внутри него и что он умеет делать.

Для это есть отличная статья "What happens when ... Kubernetes edition!" (перевод). В ней рассматривается весь жизненный цикл от команды с kubectl до старта контейнера в Pod`е сквозь `kube-apiserver, etcd, различные controllers, kubelet, CRI, CNI и т.д.

С точки зрения безопасности тут поднимаются моменты связанные с:
- клиентской аутентификацией
- процессом авторизации
- назначением и работой admission controllers

Если вам не терпится сразу что-то вводить и пытаться поломать Kubernetes, то в достаточно популярном GitHub проекте PayloadsAllTheThings есть раздел и по Kubernetes. Там собраны самые базовые команды, ресурсы, что могут пригодиться при пентесте Kubernetes.