AWS boto3 user vs role

Question

I am trying to follow best practices, but the documentation is not clear to me. I have a python script running locally that will move some files from my local drive to S3 for processing. Lambda picks it up from there and does the rest. So far I set up an AWS User for this process, and connected it to a "policy" that only has access to the needed resources.

Next step is to move my scripts to a docker container in my local server. But I thought best practice would be to use a Role with policies, instead of a User with policies. However, according to this documentation... in order to AssumeRole... I have to first be signed in as a user.

The calls to AWS STS AssumeRole must be signed with the access key ID and secret access key of an existing IAM user or by using existing temporary credentials such as those from another role. (You cannot call AssumeRole with the access key for the root account.) The credentials can be in environment variables or in a configuration file and will be discovered automatically by the boto3.client() function.

So no matter what, I'll need to embed my user credentials into my docker image (or at least a separate secrets file) If that is the case, then it seems adding a "Role" in the middle between the User and the Policies seems completely useless and redundant. Can anyone confirm or correct?

Answer 1

Roles and policies are for services running in AWS environments. For a Role you define a Trust Policy. The Trust Policy defines what principal (User, Role, AWS Service etc.) can assume it. You also define the permissions that the principal which assumes it has to access AWS services.

For services running inside AWS (EC2, Lambda, ECS), it is always possible to select an IAM role, which will be assumed by your service. This way your application will always get temporary credentials corresponding to the IAM role and you should never use an AWS Access Key Id and Secret.

However, this isn't possible for services running locally or outside of AWS environment. For your Docker container running locally, the only real option would be to create an Access Key ID and Secret and copy it there. There are still some things you can do to keep your account secure:

• Follow the least privilege principal. Create a policy that provides access to only the absolutely required resources.
• Create a user (programmatic access only) and add the policy. Use AWS Access Key ID and Secret of this user for your Docker container.
• Make sure that the AWS Credentials are rotated regularly.
• Make sure that the secrets aren't committed in source control, prefer a secrets file or a Vault system than environmental variables.

Consult this documentation page for other security best practices.