Skip to content
This repository has been archived by the owner on Jul 15, 2022. It is now read-only.

Remove Security Templates #3

Closed
Rabadash8820 opened this issue Mar 29, 2017 · 0 comments
Closed

Remove Security Templates #3

Rabadash8820 opened this issue Mar 29, 2017 · 0 comments
Assignees
Labels

Comments

@Rabadash8820
Copy link
Owner

Rabadash8820 commented Mar 29, 2017

We should move away from defining security resources in CloudFormation templates. This includes IAM users, groups, policies, and ACM certificates. Why?

  1. It's a hassle to make a new CF template every time we want to start using a new AWS service, especially when they just contain IAM groups with boilerplate policies like <Service>FullAccess and/or <Service>ReadOnly .
  2. Most of those "security" templates are super basic anyway, all they do is define the IAM entities. Creating the stack is no simpler than just creating the IAM entities manually. In fact, when first creating new IAM entities, the "edit template, put into bucket, update CF stack, test" loop, kind of slows iteration.
  3. Defining all these IAM entities ahead of time defeats the principle of least privilege. Unless we actually have a need for AWS users to have these permissions, we shouldn't be defining all these administrative groups with no users in them.
  4. Several other AWS security resources cannot be allocated in stacks anyway, including EC2 key pairs. Rather than having some security resources defined in stacks and some defined manually, we'll just define them all manually.
  5. Resource-based policies are less flexible than IAM policies because they can only be applied to one resource, so there's no need to define them in CF templates either way.

So, going forward, whenever possible, security resources should be set up manually, and referenced as parameters when required by CF stacks. The only security resources that may need to be defined in CF templates are IAM roles, which are required by some resources and often have complex policies that are inconvenient to set up manually. Some IAM entities with complex policies may still have their policy documents versioned over time (e.g., when Access Advisor reveals unnecessary permissions); however, these versioned policies should be in private repos.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

1 participant