Use AWS roles instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY

If the server is compromised, the attacker can easily get AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY from the environment, with which they can do anything.

In stead, the AWS best practice is to create an IAM role and attach the IAM to the instance that requires the specific permissions, like for example in the default cookiecutter-django setup, it’s the S3FullPermission for writing the static files.

Then we can safely remove the following:

env.example: https://github.com/pydanny/cookiecutter-django/blob/master/{{cookiecutter.project_slug}}/env.example?#L18:L19

production.py: https://github.com/pydanny/cookiecutter-django/blob/master/{{cookiecutter.project_slug}}/env.example?#L18:L19

[sfdye]

@browniebroke Yes, I have used it in one of my production projects.

Happy to provide some background, according boto3 doc here, if no credentials are provided, boto3 will search for IAM role attached to the EC2 instance automatically.

Sure, if you use the key and secret from your root account, that’s is bad practice. However, what I’ve done in the past, is to create an IAM role used only by a deploy user, with restricted access to S3. Then I created a Key and Secret for that user, and that’s what I’m using in my project.

I guess this really comes down to the question of IAM user V.S. IAM role. Here is an excerpt from the AWS [FAQ]:(https://aws.amazon.com/iam/faqs/)

Q: What is the difference between an IAM role and an IAM user? An IAM user has permanent long-term credentials and is used to directly interact with AWS services. An IAM role does not have any credentials and cannot make direct requests to AWS services. IAM roles are meant to be assumed by authorized entities, such as IAM users, applications, or an AWS service such as EC2.

So I think if we don’t want to give long-term credentials and just granting access to certain AWS service (like S3), IAM role is more suitable for this job. What do you think?

[jayfk]

This will only work on AWS, though. We are currently supporting a wide range of different deployments.

Creating an IAM role and giving it only prrmissions for s3 is the better approach in this regard.