GKE metadata-proxy: элегантный способ получения JWT без дыр в RBAC

GKE metadata-proxy: элегантный способ получения JWT без дыр в RBAC

Недавно беседовали с коллегой про Workload Identity Federation в GKE и выяснилось, что не все знают, как metadata-proxy получает JWT токен от имени пода.

А вы знаете, как это работает под капотом?

Что такое WIF?

Простая идея: токен пода обменивается на cloud token для доступа к облачным API. Никаких статических ключей!

Два подхода к безопасности:

❌ Небезопасный подход (как в эмуляторе):

rules:

- apiGroups: [""]

resources: [serviceaccounts/token]

verbs: [create]

Критическая уязвимость! Такая роль позволяет получить JWT токен от ЛЮБОГО ServiceAccount в кластере!

✅ Элегантное решение GKE:

1. Использует kubeconfig от kubelet (у него есть права только на поды своей ноды)

2. Запрашивает токен с указанием реально существующего объекта в кубере, который к тому же привязан к конкренной ноде:

kubectl create token azalio-meta-sa \

--namespace azalio-meta \

--bound-object-kind Pod \

--bound-object-name test-pod \

--bound-object-uid 5094d128-8f9b-463d

Почему это безопасно?

- metadata-proxy может получить токен только для подов на своей ноде

- Токен привязан к конкретному поду через UID

- Нет доступа к ServiceAccount подов других нод

**Как работает весь процесс:**

(картинка в комментариях)

1. Pod → metadata-proxy: GET /computeMetadata/.../token

2. proxy → K8s API: create token (ограничен нодой + Pod UID)

3. proxy → Google STS: обмен JWT → Access Token

4. STS → proxy → Pod: Access Token

5. Pod → Google API: работа с нужными сервисами

Полезные ссылки:

- Официальная документация GKE Workload Identity

- Детальный разбор безопасности WIF

- Пример настройки WI в GKE

- Bound service account tokens.

Что запомнить:

Прав выдаваемых kubeconfig'у kubelet хватает чтобы выписать токен от имени SA пода запущенного на ноде.

Вопрос: у какого российского облачного провайдера есть WIF? 😉

#kubernetes #security #gke #workloadidentity #cloudsecurity