Как отправить электронное письмо через SES с временными учетными данными, специфичными для SES? - PullRequest
0 голосов
/ 18 сентября 2018

На этой странице показано, как отправить электронное письмо с использованием SES.Пример работает путем считывания учетных данных из ~/.aws/credentials, которые являются корневыми (но «общими» ??) учетными данными.

В различных местах документация рекомендует не использовать корневые учетные данные.

В качестве опции упоминается получение временных учетных данных с использованием ролей , однако assume_role() не определено для клиентских объектов SES.

Как отправить электронное письмо через SES с временными учетными данными, специфичными для SES?

Обновление

Контекстом для моего вопроса является приложение, работающее на экземпляре EC2.

Ответы [ 2 ]

0 голосов
/ 18 сентября 2018

Есть несколько частей к этому.

Сначала вам нужна политика 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 другого сервиса. Все это происходит за кадром.

0 голосов
/ 18 сентября 2018

Два варианта ...

Вы можете создать учетные данные пользователя IAM с соответствующими разрешениями и поместить их в файл ~./aws/credentials. Тогда ваше приложение найдет их и использует для подключения к Amazon SES.

Или ваше приложение может использовать набор учетных данных пользователя IAM для вызова assume_role() (который является командой IAM). Это вернет набор временных учетных данных, которые можно использовать с Amazon SES. Однако, если вы собираетесь предоставить набор учетных данных, которые будут использоваться для вызова assume_role(), то вы также можете просто использовать эти учетные данные напрямую с Amazon SES.

Пользователь IAM может использоваться для людей ИЛИ приложений.

...