- Вопрос или проблема
- Ответ или решение
- 1. Контекст использования sts:AssumeRoleWithWebIdentity
- 2. Процесс аутентификации
- Этап 1: Получение токена Kubernetes
- Этап 2: Запрос к sts:AssumeRoleWithWebIdentity
- Этап 3: Валидация токена
- Этап 4: Получение временных учетных данных
- 3. Настройка IAM ролей и доверительных отношений
- Заключение
Вопрос или проблема
Мне интересно, как именно IAM роли для сервисных аккаунтов аутентифицируют запросы на принятие роли с использованием действия sts:AssumeRoleWithWebIdentity, когда роль находится в другом аккаунте? Документация позволила мне настроить мое решение, но не совсем очевидно (по крайней мере для меня), как это работает.
- Межаккаунтные IAM роли для сервисных аккаунтов Kubernetes
- Включение межаккаунтного доступа к ресурсам кластера Amazon EKS
Из того, что я нашел на данный момент, я с разумной достоверностью могу утверждать следующее.
- Поставщик идентификации, прикрепленный к кластеру в аккаунте A, проецирует токен на том или ином объеме в (например) дополнении
external-dns, который может использовать прикрепленный сервисный аккаунт. - Сервисный аккаунт делает запрос на принятие необходимой роли в другом аккаунте, используя действие
sts:AssumeRoleWithWebIdentity. - Роль аутентифицирует запрос на принятие этой роли, используя другого поставщика идентификации, который имеет тот же URL, что и тот, который прикреплен к кластеру.
На этом ограничение моих знаний в данный момент заканчивается. Как именно роль аутентифицирует запрос на принятие ее? Я предполагаю, что токен, передаваемый в запросе AssumeRoleWithWebIdentity, проверяется поставщиком идентификации по отношению к кластеру EKS, чтобы подтвердить его действительность? Если кто-то сможет пояснить, как именно работает этот процесс, я буду признателен.
Ответ или решение
Для понимания того, как осуществляется аутентификация запросов на получение IAM ролей с использованием действия sts:AssumeRoleWithWebIdentity, особенно в контексте кросс-аккаунтной работы, давайте подробно рассмотрим каждый шаг этого процесса.
1. Контекст использования sts:AssumeRoleWithWebIdentity
Когда вы используете sts:AssumeRoleWithWebIdentity, это действие позволяет вам получить временные учетные данные для доступа к AWS ресурсам с использованием токена идентификации от внешнего поставщика идентификации (IdP), например, OIDC (OpenID Connect). В случае интеграции с Amazon EKS (Elastic Kubernetes Service), это токен выдается Kubernetes, когда пользователь аутентифицируется в кластере.
2. Процесс аутентификации
Процесс можно разбить на несколько ключевых этапов:
Этап 1: Получение токена Kubernetes
Сначала, когда под (pod) в вашем кластере Kubernetes делает запрос, например, на получение доступа к ресурсу, он получает JWT (JSON Web Token) от API сервера Kubernetes. Этот токен записывается в монтируемый том, доступный для контейнера, в котором работает ваш основной сервис.
Этап 2: Запрос к sts:AssumeRoleWithWebIdentity
После получения токена, под использует его для аутентификации своего запроса на выполнение действия sts:AssumeRoleWithWebIdentity. Запрос включает:
RoleArn: ARN вашей IAM роли, которую вы хотите получить.WebIdentityToken: сам токен JWT, полученный от Kubernetes.
Этап 3: Валидация токена
На этом этапе система AWS проверяет токен. Процесс валидации включает:
- Проверка подписи: AWS использует публичный ключ поставщика идентификации (IdP) для проверки подписи токена JWT. Этот ключ можно получить из метаданных вашего IdP.
- Проверка сроков действия: Токен имеет временные метки, и AWS проверяет, действителен ли он (не истек ли срок его действия).
- Проверка целевой аудитории (aud): AWS также проверяет, что поле "aud" в токене соответствует ожидаемому идентификатору (client ID) вашего приложения или роли.
Если токен успешно проходит все проверки, запрос считается аутентифицированным.
Этап 4: Получение временных учетных данных
После успешной валидации, AWS возвращает временные учетные данные (Access Key, Secret Key и Session Token) для использования с IAM ролью.
3. Настройка IAM ролей и доверительных отношений
Для успешной работы процесса, необходимо правильно настроить IAM роли и доверительные отношения. Роль, которую вы хотите использовать, должна иметь политику доверия, разрешающую доступ со стороны Service Account из вашего кластера Kubernetes. Это делается с помощью использования ARN вашего IdP, идентифицирующего тот, который вы используете для аутентификации.
Заключение
В конечном итоге, аутентификация для кросс-аккаунтных запросов на использование sts:AssumeRoleWithWebIdentity обеспечивает безопасный доступ к ресурсам AWS через интеграцию IAM ролей для сервисных аккаунтов Kubernetes. Процесс включает несколько уровней валидации, что гарантирует надежность и безопасность.
Такое понимание работы механизмов AWS позволит вам более эффективно настраивать ваши системы и интеграции, а также лучше анализировать потенциальные проблемы и их решения.