Интересная статья "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.

В открытом доступе появился PoC эксплоит для CVE-2020-10749 для проведения Kubernetes MitM атаки через отправку специального ICMPv6 Router Advertisement (RA) сообщения. О деталях данной проблемы я писал ранее.

Kubernetes Goat - это специально заготовленный Kubernetes кластер с классическими уязвимостями, слабостями и проблемами для обучающих целей. Серия Goat достаточно популярно в security сообществе - есть и web-приложения, mobile-приложения и т.д. И вот очередь дошла и до Kubernetes.

На текущий момент Kubernetes Goat содержит 11 уязвимых сценариев и 3 для знакомства с инструментами Docker CIS Benchmarks, Kubernetes CIS Benchmarks и Hacker Container. Видно, что проект новый и сценариев мало и они не блещут хорошим разнообразием. Но для самого старта сойдет. Уязвимые сценарии:
- Sensitive keys in code bases
- DIND(docker-in-docker) exploitation
- SSRF in K8S world
- Container escape to access host system
- Attacking private registry
- NodePort exposed services
- Helm v2 tiller to PwN the cluster
- Analysing crypto miner container
- Kubernetes Namespaces bypass
- Gaining environment information
- DoS the memory/cpu resources

29 июня состоится однодневная, виртуальная, бесплатная конференция `fwd:cloudsec`. Данная конференция специализируется на докладах про безопасность AWS, GCP, Azure и, конечно, Kubernetes.

При запуске kube-controller-manager убедитесь, что используется ключ --use-service-account-credentials. Он говорит о том, что будут использоваться специализированные service account credentials для каждого контроллера. Иначе все контроллеры будут запущены от service account, принадлежащему `kube-controller-manager` и включающему все права для всех контроллеров. В итоге это, при компрометации service account на каком-либо из контроллеров атакующий получит чрезвычайно мощный service account. Используйте --use-service-account-credentials, чтобы минимизировать возможные последствия при компрометации какого-либо контроллера.

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

Краткие выводы:
- Все сканеры дали разные результаты как по количеству, так и по уровню критичности
- Все сканеры поддерживают разные наборы базовых изображений
- Даже в полностью обновленном базовом образе все еще могут быть известные CVE

Kubernetes опубликовал "Pod Security Standards", где подробно объясняет какие настройки, когда, где и как использовать в Pod Security Policy. Для этого они все политики разделили на 3 типа:
- Privileged - неограниченная политика, предоставляющая большую свободу, позволяет проводить хорошо известные поднятия привилегий.
- Baseline/Default - минимально закручиваем гайки чтобы предотвратить хорошо известные поднятия привилегий.
- Restricted - максимально закручиваем гайки.

Конференция fwd:cloudsec 2020, о которой мы писали недавно, сейчас в прямом эфире!