STS-токены

Назначение

STS-токены позволяют приложениям и автоматизированным системам получать временные учётные данные для работы с S3 API. Вместо постоянной передачи долгоживущих ключей пользователя система выдаёт ограниченный по времени набор credentials:

• AccessKeyId;
• SecretAccessKey;
• SessionToken;
• время окончания действия Expiration.

Такой механизм подходит для интеграций, фоновых заданий и других автоматизированных сценариев, которым доступ к объектам нужен только на ограниченный срок, а также упрощает подключение готовых решений, рассчитанных на стандартный сценарий AWS STS.

Функция не требует отдельного включения: в релизе, где она доступна, API работает по умолчанию на S3-интерфейсе рабочей области.

Как работает STS

1. Пользователь или приложение с постоянными S3-credentials вызывает метод AssumeRole на STS endpoint рабочей области.
2. ЗАКРОМА.Хранение проверяет подпись запроса и наличие у субъекта права sts:AssumeRole в применимой политике доступа.
3. Сервис возвращает временные AccessKeyId (с префиксом ASIA), SecretAccessKey и SessionToken, а также срок их действия.
4. Клиент использует все три значения при выполнении обычных S3-операций: запрос подписывается по AWS Signature Version 4 (SigV4), а SessionToken передаётся вместе с запросом (заголовок X-Amz-Security-Token или query-параметр).
5. При каждом запросе система проверяет подпись, подлинность и срок действия токена, состояние родительского пользователя и его ключа, а также применимые политики доступа.

Временные credentials не создают отдельную постоянную учётную запись и не хранятся на стороне сервиса как самостоятельные ключи доступа — необходимые для проверки сведения содержатся в защищённом токене (JWT).

Параметр RoleArn

Параметры AWS вроде RoleArn принимаются для совместимости с AWS CLI и SDK, но в текущей реализации не влияют на выбор identity: временная сессия наследует пользователя — владельца родительского статического ключа.

Поддерживаемые методы

RoleSessionName, переданный при вызове AssumeRole, идентифицирует конкретную временную сессию (в токене, ARN сессии и параметрах аудита выдачи). Рекомендуется задавать осмысленное и уникальное имя. Если имя не передано, используется значение по умолчанию session.

Кто может получать STS-токены

Вызов AssumeRole доступен не всем пользователям автоматически — право на эту операцию (sts:AssumeRole) назначается через политики доступа ЗАКРОМА.Хранение. Временные credentials может получить любой тип пользователя, для которого явно разрешён AssumeRole, включая локального пользователя рабочей области. Само по себе наличие постоянных S3-ключей не означает, что их владелец может выпускать STS-токены.

Права временной сессии

STS-токен не может расширить права пользователя, от имени которого он выпущен.

Если при вызове AssumeRole не передана дополнительная session policy, временная сессия наследует S3-операции, разрешённые родительскому пользователю политиками доступа. Если session policy передана, она может только сузить доступ. Эффективные права временной сессии — это пересечение операций, разрешённых родительскому пользователю политиками доступа, и операций, разрешённых session policy.

Например, если политика пользователя разрешает загрузку и удаление объектов, а session policy разрешает только загрузку, временная сессия сможет загружать объекты, но не сможет их удалять.

Права, назначенные через ACL, не наследуются

Права, предоставленные родительскому пользователю только через ACL, не наследуются его временной STS-сессией. Для запросов с временными credentials ACL-fallback не применяется. Чтобы STS-сессия получила доступ к объекту, требуемая операция должна быть явно разрешена политикой доступа.

Срок действия и отзыв токена

По умолчанию временные credentials выдаются на один час (3600 секунд; значение задаётся конфигурацией gateway). Другой срок можно запросить параметром DurationSeconds в пределах минимума и максимума конфигурации (по умолчанию от 15 минут до 1 года).

После наступления Expiration токен перестаёт действовать, и приложение должно получить новый набор credentials.

Индивидуальный отзыв не поддерживается

Отозвать уже выданный STS-токен по отдельности в текущей реализации нельзя — токен действует до истечения заданного срока. Рекомендуется выдавать токен на минимально необходимое время, ограничивать session policy только нужными операциями и ресурсами, не передавать credentials между независимыми приложениями и не записывать SecretAccessKey/SessionToken в журналы. При подозрении на компрометацию используйте отзыв или ротацию родительского access key (см. Управление ключами доступа).

Использование через AWS CLI

Для получения временных credentials нужны: endpoint рабочей области (тот же, что используется для S3), постоянные credentials пользователя, которому разрешён AssumeRole, --role-arn (обязателен для AWS CLI, на логику выдачи не влияет) и --role-session-name.

Copy
1ENDPOINT='https://<workspace-gateway-host>'
2
3aws sts assume-role \
4  --endpoint-url "$ENDPOINT" \
5  --region us-east-1 \
6  --role-arn 'arn:aws:iam::<workspace>:role/unused' \
7  --role-session-name '<session-name>' \
8  --duration-seconds 3600

Опционально можно передать session policy через --policy file://session-policy.json.

В ответе возвращается блок Credentials:

Copy
1{
2  "Credentials": {
3    "AccessKeyId": "<temporary-access-key-id>",
4    "SecretAccessKey": "<temporary-secret-access-key>",
5    "SessionToken": "<session-token>",
6    "Expiration": "<expiration-timestamp>"
7  }
8}

Для выполнения S3-операций необходимо передать клиенту все три значения:

Copy
1export AWS_ACCESS_KEY_ID='<temporary-access-key-id>'
2export AWS_SECRET_ACCESS_KEY='<temporary-secret-access-key>'
3export AWS_SESSION_TOKEN='<session-token>'
4
5aws s3api list-objects-v2 \
6  --endpoint-url "$ENDPOINT" \
7  --region us-east-1 \
8  --bucket '<bucket-name>'

SessionToken обязателен

Если указать только AccessKeyId и SecretAccessKey, запрос с временными credentials не будет аутентифицирован — для STS-сессии обязателен SessionToken.

Проверить identity можно с помощью GetCallerIdentity на том же endpoint:

Copy
1aws sts get-caller-identity --endpoint-url "$ENDPOINT" --region us-east-1

Использование через SDK и сторонние S3-клиенты

Подходит любой клиент, который одновременно подписывает запросы по SigV4, поддерживает временные credentials, передаёт SessionToken вместе с AccessKeyId/SecretAccessKey и позволяет указать пользовательский endpoint рабочей области. Клиент, принимающий только пару AccessKeyId/SecretAccessKey, для работы с STS-токеном не подходит.

Использование через zcli

zcli может вызвать AssumeRole командой zcli sts assume-role (алиас sts ar) — запрос идёт на S3 STS endpoint рабочей области с помощью JWT-аутентификации. Полученные временные credentials выводятся в JSON.

zcli не использует полученный токен

zcli не подставляет SessionToken в последующие команды работы с объектами — session token из ответа предназначен для внешних клиентов (AWS CLI, SDK и т. п.). Для S3-операций с временными credentials используйте AWS CLI, совместимый SDK или другой клиент с поддержкой session token.

Endpoint и аудит

Для внешних клиентов (AWS CLI, SDK и т. п.) STS API размещается на S3-интерфейсе рабочей области (POST /?Action=<AssumeRole|GetCallerIdentity>&Version=2011-06-15) — тот же базовый URL, что и для обычных S3-операций. zcli обращается к AssumeRole через собственный служебный канал (JWT-аутентификация), а не через этот S3-интерфейс — подробнее см. CLI.

Выпуск временных credentials (AssumeRole) регистрируется в аудите от имени родительского пользователя. Последующие S3-операции с временными credentials в поле пользователя аудита также отражаются как операции родительского пользователя — имя сессии и временный access key в этом поле не подставляются автоматически.

Возможные причины отказа в доступе

Ограничения

• Индивидуальный отзыв выпущенного STS-токена не поддерживается.
• Права, полученные родительским пользователем только через ACL, не переходят к временной сессии.
• RoleArn и ряд других AWS-параметров принимаются для совместимости с клиентами, но не задают отдельную IAM-роль.
• zcli может получить временные credentials, но не использует их для S3-операций.
• Клиент обязан поддерживать SigV4 и передачу SessionToken.