davidski / vulnpryer-aws-orchestration

🎯☁️Automated deployment of a VulnPryer pipline on AWS
http://vulnpryer.net
2 stars 2 forks source link

Good practice recommendation on OpsWorks Roles #5

Closed davidski closed 9 years ago

davidski commented 9 years ago

This deployment is creating a custom OpsWorks service role in addition to the resource role for the instances. Do you suggest using a custom role for each OpsWork stack? I've been using the default opswork role for the ELK stack. Is it a good practice to run custom roles for everything or is it easy/safe to use a single role for all opsworks service activities and then use specific instance roles to control what those app stacks can do?

abbyyacat commented 9 years ago

For security reasons, it is always a good practice to create custom roles for every purpose/duty/stack. This will also be beneficial in case permission modification specific to each stack is necessary in the future.

davidski commented 9 years ago

I don't understand the threat model that would make having so many different service roles advisable. The policy on this role is generic across all EC2 and other services, so a compromise of this role gives the same permissions as any other OpsWorks service. The ELK stack does not use a custom OpsWork Service role, so this approach looks inconsistent from other recently generated work.

I'm going to comment out this section of the code pending a better understanding of what this is meant to address.