Permission boundaries: make sure roles can't create roles with more permissions than themselves, even when they have multiple attached policies

Question

Imagine the following scenario:

- I have a role that has multiple policies attached to it, specifying all the permissions the role has. Let's call it RoleA
- I need to attached multiple policies to RoleA because one policy with all the necessary permissions would break the policy's allowed chars limit (6144 chars per policy)
- RoleA needs to be able to create other roles and policies
- To prevent privilege escalation, I would like to put a condition that the roles created by RoleA need to have a permission boundary
- So that I don't have to manage multiple permissions boundaries, I would like the roles created by RoleA to have multiple permissions boundaries, these permissions boundaries being the policies I attach to RoleA
- With the above, I make sure that although RoleA can create roles, all the roles RoleA creates do not have escalated permissions, because the created roles need to have RoleA's policies attached as permissions boundaries

However, when a role is created, we can only specify one permission boundary. Like mentioned above, since RoleA has multiple permissions, I can't create a single permission boundary policy matching RoleA's permissions.

As far as I understand, this means that I, as an admin, either:
- Manage multiple permissions boundaries policies according to the created roles use case, and RoleA can pick the appropriate one for the roles they create
- Or I remove RoleA's permission to create roles, and instead manage the roles they need, still allowing them to use the roles as needed

My questions are:
- Is there a better approach?
- If there isn't a better approach, what's the best approach out of the two?

Answer

The challenge you're facing is a common one in managing AWS IAM roles and permissions, especially when trying to adhere to the principle of least privilege while avoiding privilege escalation. Here are some insights into your situation:

1. **Using Multiple Permission Boundaries**: AWS currently does not support attaching multiple permission boundaries to a single IAM role. Permission boundaries are designed to be a single policy that defines the maximum permissions an IAM role can have.

2. **Better Approach?**: There might not be a fundamentally "better" approach as AWS IAM is designed with certain constraints. However, you can optimize within these constraints. For instance, you could create a set of standardized permission boundary policies that correspond to different levels of access within your organization. These can be attached to roles as needed, depending on the level of access required.

3. **Best Approach**: Between the two options you've listed:
   - **Managing Multiple Permission Boundaries**: This approach provides RoleA with the ability to create roles within certain limits. It offers more flexibility but requires diligent management of permission boundaries to ensure they are appropriately scoped and updated.
   - **Central Management of Role Creation**: Removing RoleA's permission to create roles and instead centralizing role creation with the admin can be more secure as it puts the creation and assignment of roles under strict control. However, it reduces flexibility and increases the administrative burden.

Considering these points, the best approach will depend on your organization's specific needs for autonomy versus control, as well as your capacity to manage permission boundaries effectively.

If a high degree of autonomy for RoleA is not critical and you want to minimize risk, centralizing role creation and management might be more suitable. You'd maintain strict control over permissions, and RoleA would simply use the roles as needed.

If RoleA needs the flexibility to create roles dynamically and you're able to manage permission boundaries well, then managing multiple permission boundaries would be the way to go. This allows for autonomy while still placing checks on the level of access roles can have.

In either case, it's essential to regularly audit permissions and boundaries to ensure they are as intended and that no unnecessary privileges exist. Automation tools and services like AWS CloudTrail, AWS Config, and third-party solutions can aid in monitoring and managing these configurations at scale.

Permission boundaries: make sure roles can't create roles with more permissions than themselves, even when they have multiple attached policies

Relevant content