Есть несколько частей к этому.
Сначала вам нужна политика IAM. Вы можете использовать одну из встроенных политик, например AmazonSESFullAccess
, или создать свою собственную. Владелец определенной политики сможет получить доступ к ресурсам и действиям, определенным в политике. Вы можете создать эту политику вручную или работать через консоль AWS, и она проведет вас через нее. IAM -> Политики -> Создать политику
Во-вторых, вам понадобится роль. Также легко сделать в консоли. IAM -> Роли -> Создать роль. Доверенное лицо - сервис AWS. Выделите EC2. На следующем экране выберите политику, которую вы хотите связать с этой ролью. Это политика, которую вы создали выше. Если у вашего EC2 уже есть роль, вы можете добавить политику IAM к этой роли. Назначение политики IAM роли - это то, что они называют политикой доверия.
Теперь любой код, который запускается на вашем экземпляре EC2, сможет отправлять сообщения в службу SES. EC2 берет на себя роль, назначенную ему. И политика SES определена для этой роли. Это позволит EC2 получить временные учетные данные (за кадром).
Предыстория заключается в следующем. Любой вызов API службы AWS должен иметь ключ и секрет. Когда вы делаете вызовы API с вашего локального компьютера, вы можете использовать свой личный ключ и секретный (или даже корневой). Когда вам нужно сделать вызовы API из другой службы, у вас нет этого ключа и секрета. Было бы небезопасно или практично хранить учетные данные на EC2. Или даже хуже, в ведре S3. Вот почему AWS предложила концепцию Role
. Роли могут запрашивать временные учетные данные у внутренней службы, называемой Simple Token Service (STS). Например, к экземпляру EC2 прикреплена роль. И если к этой роли прикреплена правильная политика, экземпляр EC2 может запросить получение временных учетных данных для вызова API другого сервиса. Все это происходит за кадром.