2

This page shows how to send an email using SES. The example works by reading the credentials from ~/.aws/credentials, which are the root (yet "shared"??) credentials.

The documentation advises in various places against using the root credentials.

Acquiring temporary credentials using roles is mentioned as an option, yet assume_role() is not defined for SES client objects.

How do I send an email through SES with temporary SES-specific credentials?

Update

The context for my question is an application running on an EC2 instance.

Calaf
  • 10,113
  • 15
  • 57
  • 120
  • Which application will send the emails using SES? Is it an EC2 instance? If so, that instance will need permission to assume a role that can send emails in STS. – Olivier De Meulder Sep 18 '18 at 03:01
  • @OlivierDeMeulder yes, indeed. I updated the question. If you decide to answer, could you provide a link to the documentation in question, or use a few more words? – Calaf Sep 18 '18 at 13:42

2 Answers2

1

Two options...

You could create IAM User credentials with the appropriate permissions and put them in the ~./aws/credentials file. Then your application will find them and use them to connect with Amazon SES.

Or, your application could use a set of IAM User credentials to call assume_role() (which is an IAM command). This will return a set of temporary credentials that could be used with Amazon SES. However, if you are going to provide a set of credentials that will be used to call assume_role(), then you may as well just use those credentials directly with Amazon SES.

An IAM User can be used for people OR applications.

John Rotenstein
  • 241,921
  • 22
  • 380
  • 470
  • What you call here IAM user identities are also known as _named profiles_ in the AWS documentation; is that correct, or is there some subtle reason why these are given two distinct names in the documentation? In any case, I am confused about the reason why a collection of IAM perpetual access keys offer any significant advantage over the root access key. I asked: https://stackoverflow.com/q/52387859/704972 – Calaf Sep 18 '18 at 13:38
  • Root access can never be blocked. Anyone with root credentials has complete access to the AWS account. Instead, a subset of permissions can be assigned to an IAM User, so that a person (or application) only has limited access to the account, such as the ability to launch EC2 instances but not change VPC configurations. Always grant the least amount of privileges as necessary to avoid accidental or intentional damage to services. – John Rotenstein Sep 18 '18 at 14:30
1

There are a few pieces to this.

First you need an IAM policy. You can use one of the built-in policies, such as AmazonSESFullAccess or you can create your own. The holder of a particular policy will be able to access the resources and actions defined in the policy. You can create this policy manually, or work through the AWS console and it will walk you through it. IAM --> Policies --> Create Policy

Secondly, you will need a role. Also, easily done in the console. IAM --> Roles --> Create role. Trusted entity is AWS service. Highlight EC2. In the next screen, select the policy you want to associate with this role. This is the policy you created above. If your EC2 already has a role, then you can add the IAM policy to this role. Assigning an IAM policy to a role, is what they refer to as a trust policy.

Now any code that runs on your EC2 instance will be able to send messages to your SES service. The EC2 assumes the role assigned to it. And the SES policy is defined for that role. This will allow EC2 to get temporary credentials (behind the scenes).

The back story is as follows. Any API call to an AWS service needs to have a key and secret. When you make API calls from your local computer, you may use your personal key and secret (or even root ones). When you need to make API calls from another service, you do not have that key and secret. It would not be secure or practical to store the credentials on an EC2. Or even worse, in an S3 bucket. That is why AWS came up with the Role concept. Roles can request temporary credentials from an internal service called Simple Token Service (STS). A role is attached to an EC2 instance for example. And if the right policy is attached to that role, the EC2 instance can request to get temporary credentials to make an API call to another service. All of this happens behind the scenes.

Olivier De Meulder
  • 2,493
  • 3
  • 25
  • 30
  • Strange. I had gone down the steps you describe (among many more), but I was missing the clincher--the place where I would retrieve some access key+password from the role and pass it on to the code in the EC2 instance. With your answer it appears there is no such thing. AWS handles the access permissions internally (via IP, or who knows what). Is this actually documented? Or are they worried that disclosure of how they implement security would tip off attackers? – Calaf Sep 18 '18 at 22:34