Impersonate сервисного аккаунта — метод аутентификации, при котором инициатор получает токен доступа сервисного аккаунта без использования его ключей доступа.
Impersonate доступен на платформе Evolution.
Токен запрашивает субъект-инициатор: пользователь или сервисный аккаунт с правом на impersonate. Токены инициатора и сервисного аккаунта отличаются друг от друга, права инициатора за счет impersonate не изменяются.
Инициатор получает права сервисного аккаунта без необходимости создавать, передавать и хранить ключи доступа. В токене сохраняется идентификатор инициатора, поэтому действия с таким токеном можно связать с конкретным пользователем или сервисным аккаунтом.
Impersonate состоит из трех этапов:
Администратор выдает право на impersonate: назначает субъекту роль iam.serviceaccount.impersonator.
Субъектом может быть пользователь, группа пользователей или сервисный аккаунт. Роль будет назначена на конкретный сервисный аккаунт, а также на проект или организацию. Субъект сможет получать токены всех сервисных аккаунтов этого проекта или организации.
Пользователь, состоящий в группе с ролью iam.serviceaccount.impersonator, получает право на impersonate через группу.
Инициатор авторизуется своим ключом доступа или своим токеном доступа и получает токен доступа сервисного аккаунта. В запросе следует указать идентификатор нужного сервисного аккаунта.
Инициатор использует полученный токен в запросах к API так же, как обычный токен сервисного аккаунта.
Токен доступа, полученный через impersonate, содержит те же поля, что и обычный токен сервисного аккаунта:
sub — идентификатор сервисного аккаунта;
sub_type — тип субъекта, всегда service_account;
customer_id — идентификатор организации;
project_id — идентификатор проекта, если сервисный аккаунт создан в проекте.
Дополнительно в токен доступа добавляется поле act с данными инициатора:
sub — идентификатор инициатора;
sub_type — тип инициатора: user или service_account.
Поле act есть только в токене доступа, полученном через impersonate. В ID-токене такого поля нет.
Пример декодированного токена доступа сервисного аккаунта, полученного пользователем через impersonate:
{"sub": "3f4c1d2e-0000-4000-8000-000000000001","sub_type": "service_account","act": {"sub": "9a8b7c6d-0000-4000-8000-000000000002","sub_type": "user"},"customer_id": "<customer_id>","project_id": "<project_id>","typ": "Bearer","iat": 1757000000,"nbf": 1757000000,"exp": 1757003600}
Признак токена, полученного через impersonate, — непустое значение sub в поле act. По нему сервисы отличают действия инициатора от действий самого сервисного аккаунта.
При impersonate действуют следующие ограничения:
Срок действия токена, полученного через impersonate, такой же, как у обычного токена сервисного аккаунта, — по умолчанию 1 ч.
Токеном, полученным через impersonate, нельзя получить токен другого сервисного аккаунта. Цепочки impersonate запрещены.
Токен нельзя обновить: refresh-токен не выдается. По истечении срока действия инициатору необходимо запросить новый токен.
Сервисный аккаунт не может получить собственный токен через impersonate: запрос POST /api/v2/auth/impersonate с собственным идентификатором вернет ошибку 400 с кодом self_impersonation.
В запросе POST /api/v2/auth/token собственный идентификатор в поле serviceAccountId игнорируется, по ключу выдается обычный токен.
Нельзя получить токен отключенного сервисного аккаунта.