Cookiecutter-django: Use AWS roles instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY

[sfdye]

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/%7B%7Bcookiecutter.project_slug%7D%7D/env.example?#L18:L19

production.py:
https://github.com/pydanny/cookiecutter-django/blob/master/%7B%7Bcookiecutter.project_slug%7D%7D/env.example?#L18:L19

[pydanny]

I agree.

[sfdye]

Cool, I can make a PR for your to review. Basically remove these lines and update the docs with an additional step to provision an IAM role when deploying to production on aws.

---

From: Daniel Roy Greenfeld [e-mail]
Sent: Wednesday, January 17, 2018 2:08:13 PM
To: pydanny/cookiecutter-django
Cc: Wan Liuyang; Author
Subject: Re: [pydanny/cookiecutter-django] Use AWS roles instead of AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY (#1453)

I agree.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/pydanny/cookiecutter-django/issues/1453#issuecomment-358207184, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AA-CRv6ZCeEjwS6InLm_PLR01A6_fS38ks5tLY5NgaJpZM4RfP9L.

[sfdye]

Okay I will work on this and submit my PR today.

[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.

[browniebroke]

Apologies if I'm misunderstood what you mean, but reading again, I'm not sure it's going to work. Have you used it in a project? I _think_ (but happy to be proven wrong) the underlying library requires these 2 settings to be defined, they are not listed as optional.

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.

You can go one step further and only grant access to the specific bucket(s) to that user, as outlined in this tutorial.

[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?

[browniebroke]

I've been meaning to review the pull request for this, but I'm wondering if I know enough about the supported range of deployments. In theory, a Docker container isn't restricted to be deployed AWS, it could get deployed in a number of platforms.

I'm not familiar enough with the project to know what Docker platform is supported, but if there is anything else than AWS, I'd say the environment variables should stay in the env.example file.

Thoughts on this? Am I missing anything?

[sfdye]

@browniebroke you are absolutely right, even docker deployment isn't limited to AWS only. I think the best approach would probably be to include a note for AWS deployment and keep the environment variables in the env.example as they are.