- 最新
- 投票最多
- 评论最多
To save yourself from specifying every action, you can use a wildcard for API actions (write actions) like Create*. Obviously, to prevent users from making out-of-band changes, restricting write actions would suffice. For those resources/actions that support tags, you can implement Attribute Based Action Control (ABAC). Using ABAC, you can reduce the number of policies (not only SCPs but IAM policies as well). Multiple users/roles can use the same policies but have different access based on tags (attributes).
Also, you can consider using AWS Config to detect changes and apply remediation. This is more of a reactive solution but can help detect unpredicted changes.
Thinking out loud here: most AWS resources created by AWS CloudFormation that support tagging (which is nearly all of them) often get AWS-generated cloud formation tags, i.e. aws:cloudformation:stack-id
and so on. Might be worth looking into creating a policy that denies any action if these tags are present on the resources? Might not work for all resources, not all API calls support resource-level tagging conditions but that's a good "covers everything it can".
Answers from Taka_M and JohnPreston are great. I'm also looking into those methods. In addition, if you are considering even more locked-down resources, you could also provision resources via Service Catalog or an external Pipeline such as GitHub/GitLab/Bitbucket/etc.. This way you could give access to those tools instead of direct access to the resources in the console, and keep console access mostly read-only. As an example, we're looking to give EC2 console access (SSH/RDP) via Session Manager, and also restart the instance in the console, but otherwise read-only. Hope this helps.
Thank you all for all the great suggestions. I think I will start with an option of building a SCP based on CFN tags with limited console access in lower environment and try it out. For SCP, as per Taka_M's suggestion probably identifying suitable wildcards (Create* etc) makes more sense.