☸️ Ломаем и чиним Kubernetes

Kubernetes – это отличная платформа для управления контейнерами, которая в последнее время демонстрирует прорыв как в плане функциональности, так и в плане безопасности и отказоустойчивости.

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

Далее мы рассмотрим как выполнить несколько хакерских атак на Kubernetes, включая разрушение кластера, удаление сертификата и подключение ноды, и все это без простоя запускаемых сервисов.

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

Чтобы начать, давайте вспомним, что основная панель управления Kubernetes состоит из нескольких компонентов:

• etcd: Используется в качестве базы данных
• kube-apiserver: API и сердце кластера
• kube-controller-manager: Для развертывания на ресурсах Kubernetes
• kube-scheduler: Главный планировщик
• kubelets: Для запуска контейнеров непосредственно на хостах

Каждый из этих компонентов защищен набором TLS, клиентских и серверных сертификатов, целью которых является аутентификация и авторизация компонентов между собой.

Эти ресурсы нигде не хранятся в базе данных Kubernetes, за исключением некоторых случаев, а представлены в виде обычных файлов:

# tree /etc/kubernetes/pki/ /etc/kubernetes/pki/ ├── apiserver.crt ├── apiserver-etcd-client.crt ├── apiserver-etcd-client.key ├── apiserver.key ├── apiserver-kubelet-client.crt ├── apiserver-kubelet-client.key ├── ca.crt ├── ca.key ├── CTNCA.pem ├── etcd │ ├── ca.crt │ ├── ca.key │ ├── healthcheck-client.crt │ ├── healthcheck-client.key │ ├── peer.crt │ ├── peer.key │ ├── server.crt │ └── server.key ├── front-proxy-ca.crt ├── front-proxy-ca.key ├── front-proxy-client.crt ├── front-proxy-client.key ├── sa.key └── sa.pub

Сами компоненты описываются и запускаются на мастерах в виде статических подов из каталога /etc/kubernetes/manifests/.

Самое главное – знать, как из всего этого сделать функциональный кластер; представим, что упомянутые выше компоненты Kubernetes каким-то образом взаимодействуют друг с другом.

Базовая схема выглядит следующим образом:

Для общения им нужны TLS-сертификаты, которые, в принципе, можно вынести на отдельный уровень абстракции и полностью положиться на свой инструмент распространения, будь то kubeadm, kubespray или что-то еще, упоминают эксперты по пентестингу.

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

Предположим, что у нас уже есть кластер.

Начнем с самого интересного:

rm -rf /etc/kubernetes/

У мастер нод этот каталог содержит:

• Набор сертификатов и CA для etcd (c/etc/kubernetes/pki/etcd)
• Набор сертификатов и CA для Kubernetes (c/etc/kubernetes/pki)
• Kubeconfig для cluster-admin, kube-controller-manager, kube-Scheduler и kubelet (каждый также имеет сертификат CA в base64-кодировке для нашего кластера /etc/kubernetes/*.conf)
• Набор статических манифестов для etcd, kube-apiserver, kube-Scheduler и kube-controller-manager (c/etc/kubernetes/manifests)

Предположим, мы потеряли все и сразу.

Исправление проблем control plane

Чтобы избежать путаницы, исследователи рекомендуют убедиться, что все наши поды control plane также остановлены:

crictl rm `crictl ps -aq`

Следует помнить, что kubeadm по умолчанию не перезаписывает существующие сертификаты и kubeconfigs, поэтому для их повторного выпуска необходимо сначала вручную удалить их.

Начнем с восстановления etcd, потому что если у нас есть кворум (3 или более мастер-нод), то кластер etcd не запустится без присутствия большинства из них.

kubeadm init phase certs etcd-ca

Приведенная выше команда создаст новый CA для нашего кластера etcd.

Поскольку все остальные сертификаты должны быть подписаны им, мы скопируем его вместе с закрытым ключом на остальные мастер-ноды:

/etc/kubernetes/pki/etcd/ca.{key,crt}

Теперь давайте перегенерируем остальные сертификаты etcd и статические манифесты на всех нодах в control plane:

kubeadm init phase certs all
kubeadm init phase kubeconfig all
kubeadm init phase control-plane all
cp -f /etc/kubernetes/admin.conf ~/.kube/config

kubeadm init phase bootstrap-token

kubeadm init phase upload-certs --upload-certs

kubectl get cm -n kube-system extension-apiserver-authentication -o yaml

Чиним воркер ноды

Эта команда выведет список всех нод  кластера, хотя теперь все они будут находиться в состоянии NotReady:

kubectl get node

Это происходит потому, что они все еще используют старые сертификаты и ждут запросов от сервера, подписанных старым CA.

Чтобы обойти эту проблему, мы воспользуемся kubeadm:

kubeadm init phase control-plane controller-manager

Восстановление Service Accounts

Есть еще один момент.

Поскольку мы потеряли /etc/kubernetes/pki/sa.key, эксперты отмечают, что это тот же ключ, которым были подписаны jwt-токены для всех наших ServiceAccounts, поэтому нам нужно заново создать токены для каждого из них.

Это можно сделать, просто удалив поле token из всех секретов kubernetes.io/service-account-token:

kubectl get secret --all-namespaces | awk '/kubernetes.io\/service-account-token/ { print "kubectl patch secret -n " $1 " " $2 " -p {\\\"data\\\":{\\\"token\\\":null}}"}' | sh –x

kubectl get pod --field-selector 'spec.serviceAccountName!=default' --no-headers --all-namespaces | awk '{print "kubectl delete pod -n " $1 " " $2 " --wait=false --grace-period=0"}'