Каковы преимущества совместного использования роли IAM вместо ключа IAM?

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

Во-вторых, с пользователем IAM каждый раз, когда третьей стороне требуется доступ к ресурсам в вашей учетной записи, они должны иметь ключ доступа и секретный ключ вашего пользователя IAM. Если они хотят получить доступ к ресурсам вашей учетной записи из инстанса EC2, у них должен быть способ безопасно передать ключи в инстанс EC2. Если они хотят получить доступ к ресурсам из Lambda, им нужно сделать ключи доступными для Lambda. Если они хотят получить доступ к ресурсам с мобильного устройства, им необходимо передать учетные данные на мобильное устройство (где их сложнее защитить, не говоря уже о ротации).

Управление этими учетными данными — это не только дополнительная работа для третьей стороны, но и дополнительный риск для вас. Долгосрочные учетные данные для вашего пользователя IAM теперь передаются третьей стороне.

Вместо этого, используя роль IAM, вы можете разрешить третьей стороне доступ к ресурсам без передачи ваших учетных данных. Экземпляр EC2 может избежать обработки ваших учетных данных с помощью ролей экземпляра EC2. Точно так же Lambda может избежать обработки ваших учетных данных, используя роли выполнения. На мобильном устройстве есть Cognito.

Чтобы предоставить стороннему лицу доступ к принадлежащим вам ресурсам AWS, у вас есть следующие варианты:

1. [ХУДШИЙ ПОДХОД] Вы создаете пользователя IAM (скажем, Foo) и предоставляете ему необходимые разрешения, а затем делитесь ими с внешними сторонами. Это, очевидно, наихудший подход, так как теперь у вас нет разделения между теми, кто звонит на ваши ресурсы, потому что, по сути, всегда Foo звонит вам тот, кто звонит вам.
2. Вы позволяете своим клиентам создавать IAM пользователей в своих учетных записях, а затем вносить их в белый список в политике вашего ресурса. Это работает, если ваш ресурс поддерживает политики на уровне ресурсов (S3 и API Gatewaydo). Теперь, даже если они поддерживают политики на уровне ресурсов, теперь вам будет сложно внести в белый список всех таких пользователей, созданных всеми вашими клиентами, которые могут получить доступ к ресурсу.
3. Вы создаете IAM роль, предоставляете ей возможности (с точки зрения IAM политик) для доступа к вашему ресурсу, а затем вносите IAM пользователей ваших клиентов в белый список для assume этой роли. Это будет ваш способ сказать, что "this role is capable of accessing my resource and if you can assume this role, so do you". Более того, это также не позволяет вам делиться учетными данными, поскольку AWS STS выполняет всю работу по созданию временных учетных данных для вас.