Какая функциональность AWS_SESSION_TOKEN возвращается из API STS? - PullRequest
0 голосов
/ 17 ноября 2018

aws sts assume-role возвращает три поля в качестве выданных временных учетных данных.

  • AWS_ACCESS_KEY_ID
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN

Первые два имеют один и тот же формат пользовательского ключа доступа , но 3-е поле, AWS_SESSION_TOKEN, специально для временных учетных данных.

У меня есть два вопроса:

  • Если AWS_SESSION_TOKEN предназначено для представления / кодирования временной действительности, почему нам все еще нужны первые два поля (потому что после истечения срока действия нам все равно нужно будет получить еще AWS_SESSION_TOKEN )?
  • Если мой клиент дважды вызовет API STS, между двумя ответами, возвращенными из aws sts assume-role, будет / может ли AWS_ACCESS_KEY_ID совпадать?

1 Ответ

0 голосов
/ 17 ноября 2018

Я думаю, что есть только одно предположение, о котором вы можете ретранслировать: это интерфейс, предоставляемый AWS, и то, что не сформулировано специально в документации AWS, не поддерживается.

Когда создается новый программный ключ доступа, он всегда отличается, поэтому нет особого смысла в том, что он «останется неизменным между вызовами». Я думаю, что «AWS_SESSION_TOKEN» поражает, что вы должны использовать его в течение одного сеанса. Если бы это было для одного звонка, это могло бы быть названо "AWS_ONECALL_TOKEN". Я хотел бы предположить, что роль предположения STS - намного более медленная операция, чем вызов API регулятора. Мое предложение состоит в том, чтобы считать это «паролем из трех частей для одного сеанса», и ничего особенного, если вы не хотите создать собственную реализацию для аналогичной вещи. Тогда может быть очень полезно проанализировать, каковы преимущества и недостатки этого подхода.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...