You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 15, 2022. It is now read-only.
We should move away from defining security resources in CloudFormation templates. This includes IAM users, groups, policies, and ACM certificates. Why?
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 .
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered:
We should move away from defining security resources in CloudFormation templates. This includes IAM users, groups, policies, and ACM certificates. Why?
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.
The text was updated successfully, but these errors were encountered: