IAM best practices, whitepapers/patterns


Hi, all. I am looking to find some information on IAM best practices or some whitepapers/patterns (or even tools if there any) to help me refactor my IAM policies for all my services. The biggest problem im facing is that I have a lot of overlap in policies and im finding it difficult to easily write policies such that they are resuable in a few different situations where the policies only differ slightly.

For example, I may have an application stack that has a bunch of AWS resources and I need to define policies for admins that are more broad than regular engineers (who may not have delete/modify permissions to some resources), while CI/infra automation may need more broad access to provision the stack, and the stack service itself may need access to a smaller subset of resources in order to run.

The problem is that as ive added more stacks, the policies have become largely duplicated and theres no clear/easy way to reduce this duplication.

Are there any whitepaper/patterns/examples or tools that you have found have been beneficial in restructuring IAM policies, roles, and groups as your AWS resource "stacks" for different applications has grown?

2 Answers

Based on what you described, this is very common scenario, which happens. In the early phase of adoption, we tend to move fast and later it becomes an overhead.

There are few things that I'd suggest you to get started with. Start adopting following practices in phases and let new resource(IAM entities) stricytly follow the defined processes. You would eventually be able to make it better but it would take time and implementing all best practices in ago would be a touch task and may result to various failures too.

With that said, here are some of the things I'd start with:

  1. Explore permission boundaries, such as one boundary condition for federated(user) roles and one boundary for service roles
  2. Implement Service Control policies
  3. Wherever you see, policies can be reused, create manage policy instead of inline policy
  4. Split the policies wherever possible and reuse it(this way, you can reuse common portion of a policy at many places) -> remember there is a hard limit on max number of policies that can be attached to a role. Refer re:Post Knowledge Center


Hope this helps.

Comment here if you have additional questions, happy to assist.


profile pictureAWS
answered 8 months ago
  • I totally agree with this, you need to keep things simple and not over complicate things, you have the stacks with all the required permissions, and you fine grain the control by using Permission boundaries on IAM groups, and just move the users to the group you want to preform their job. and AWS SCP's are great if you have more than one account to control just create an organisation and add the SCP's to control the level of interactions you want each account to have, or add it to the root account to apply the restrictions or limits to all accounts. this way you only change the permission boundaries if needed or move users between groups to give them different access levels, or even different account,

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions