Как работает сервер метаданных GKE в Workload Identity

Question

Недавно я использовал функцию GKE Workload Identity . Мне было бы интересно узнать более подробно, как работает компонент gke-metadata-server.

1. Код клиента GCP (gcloud или другой язык sdk) переходит к метаданным метода GCE
2. Запрос на http://metadata.google.internal/path
3. (предположение) Настройка GKE_METADATA_SERVER в моем пуле узлов настраивает его для разрешения для модуля gke-metadata-server на этом узле.
4. (предположения) *Модуль 1017 * с модулем --privileged и сетью хоста имеет средство определения источника (IP-адреса модуля?), А затем поиска модуля и его учетной записи службы для проверки на наличие аннотации iam.gke.io/gcp-service-account.
5. (предположите)Прокси-сервер вызывает сервер метаданных с набором псевдо-идентификаторов pods (например, [PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]), чтобы получить токен для служебной учетной записи, аннотированной для его учетной записи службы kubernetes.
6. Если эта учетная запись имеет создателя токена / пользователя с идентификатором рабочей нагрузкиправа на учетную запись службы, по-видимому, ответ от GCP является успешным и содержит токен, который затем упаковывается и возвращается обратно в модуль вызова для аутентифицированных вызовов других API Google.

Думаю, главная загадка для меня сейчас - это проверка личности вызывающих контейнеров. Первоначально я думал, что это будет использовать API TokenReview, но теперь я не уверен, как клиентские инструменты Google узнают, как использовать токен учетной записи службы, установленный в модуль ...

Редактировать следоватьповторяющиеся вопросы:

В1: Между шагами 2 и 3, запрос к metadata.google.internal перенаправляется на прокси метаданных gke с помощью параметра GKE_METADATA_SERVER в пуле узлов?

Q2: Зачем модулю сервера метаданных нужна сеть хоста?

Q3: В видео здесь: https://youtu.be/s4NYEJDFc0M?t=2243 принимается как данность того, что модуль выполняет GCP-вызов. Как сервер метаданных GKE идентифицирует модуль, выполняющий вызов для запуска процесса?

Answer 1

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

Поставщик OIDC : работает в инфраструктуре Google, предоставляет метаданные для кластера и подписывает авторизованные JWT.

Сервер метаданных GKE : он работает как DaemonSet, то есть один экземпляр на каждом узле, предоставляет сервер метаданных для конкретного модуля (обеспечивает обратную совместимость со старыми клиентскими библиотеками), эмулирует сервер метаданных существующего узла.

Google IAM : выдает токен доступа, проверяет привязки, проверяет подписи OIDC.

Облако Google : принимает токены доступа, делает практически все.

JWT : веб-токен JSON

mTLS : защита взаимного транспортного уровня

Ниже приведены действия, поясняющие работу компонентов сервера метаданных GKE:

Шаг 1 : авторизованный пользователь связывает кластер с пространством имен.

Шаг 2 : рабочая нагрузка пытается получить доступ к службе Google Cloud с помощью клиентских библиотек.

Шаг 3 : сервер метаданных GKE собирается запроситьOIDC подписал JWT с самолета управления. Это соединение аутентифицируется с использованием взаимного соединения TLS (mTLS) с учетными данными узла.

Шаг 4 : Затем сервер метаданных GKE использует JWT, подписанный OIDC, для запроса токена доступа для [пространства имен идентификации] / [учетной записи службы Kubernetes] от IAM. IAM собирается проверить наличие соответствующих привязок в пространстве имен идентификаторов и в поставщике OIDC.

Шаг 5 : и затем IAM проверяет, что оно было подписано правильным поставщиком OIDC кластера. Затем он вернет токен доступа для [идентификационное пространство имен] / [учетная запись службы kubernetes].

Шаг 6 : Затем сервер метаданных отправит маркер доступатолько что вернулся в IAM. Затем IAM обменяет его на токен учетной записи службы GCP с коротким сроком службы после проверки соответствующих привязок.

Шаг 7 : Затем сервер метаданных GKE возвращает токен учетной записи службы GCP в рабочую нагрузку.

Шаг 8 : рабочая нагрузка может затем использовать этот токен для совершения звонков в любую облачную службу Google.

Я также нашел видео относительно идентификации рабочей нагрузки, котороеВы найдете полезными.

РЕДАКТИРОВАТЬ Ответы на дополнительные вопросы:

Ниже приведены ответы на ваши дополнительные вопросы:

Q1 : Между шагами 2 и 3, перенаправляется ли запрос metadata.google.internal на прокси-сервер метаданных gke с помощью параметра GKE_METADATA_SERVER в пуле узлов?

Выверно, GKE_METADATA_SERVER установлен в пуле узлов. Это предоставляет API метаданных для рабочих нагрузок, совместимых с API V1 Compute Metadata. Когда рабочая нагрузка пытается получить доступ к службе Google Cloud, сервер метаданных GKE выполняет поиск (сервер метаданных проверяет, существует ли в списке модуль, чей IP-адрес совпадает с входящим IP-адресом запроса), прежде чем он запрашивает токен OIDC уплоскость управления.

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

Q2 : Почему модулю сервера метаданных требуется сетевое соединение с хостом?

Сервер gke-metadata-server перехватывает все запросы сервера метаданных GCE от модулей, однако блоки, использующие сеть хоста, не перехватываются.

Q3 : Как сервер метаданных GKE идентифицирует модуль, выполняющий вызов для запуска процесса?

Элементы определяются с помощью правил iptables.