3 ms·

You can only have a single permissions boundary attached to your role that is limited to 6144 characters, which is fairly small. Use AWS accounts as your bounda

You can only have a single permissions boundary attached to your role that is limited to 6144 characters, which is fairly small. Use AWS accounts as your boundary instead.

unethical_ban 4y ago
Perm boundaries have their place, but yes, in my previous role, each department/app group was allocated their own AWS account in the organization. Maybe we didn't get as fragmented as you recommend, because you could still have similar but different groups of people within an account working on projects and permission boundaries were still used. regarding the frustrations with size limits: I feel the same about so many of the constraints in AWS IAM. Also on my gripe list: Using raw JSON to specify policy rather than a better DSL for expressing complex logic. Trying to get certain conditions properly specified can be a mind bender with the syntax provided, or be downright impossible.
- Hikikomori 4y ago
  We use both. Have a managed project where people can create their own IAM roles using defined policies for all services. For some use cases creating your own role is better so they must attach one of the roles they create with the project as their boundary when they create the role.
danw1979 4y ago
This would be great advice, but until AWS have a more solid story about resource sharing (to avoid duplicated costs for your usual boilerplate account infra) then you’ll quite quickly end up amalgamating accounts to reduce costs again, in my experience. RAM is getting there, but I tried this pattern again recently and ran headfirst into the problem of not being able to easily share a R53 zone between accounts without it descending into a mess of assume-role. I’m sold on the simplicity of small team accounts rather than larger accounts with complicated IAM policy though.
- Hikikomori 4y ago
  Why not give each account and region its own zone?

You can only have a single permissions boundary attached to your role that is limited to 6144 characters, which is fairly small. Use AWS accounts as your boundary instead.

unethical_ban 4y ago

Perm boundaries have their place, but yes, in my previous role, each department/app group was allocated their own AWS account in the organization. Maybe we didn't get as fragmented as you recommend, because you could still have similar but different groups of people within an account working on projects and permission boundaries were still used. regarding the frustrations with size limits: I feel the same about so many of the constraints in AWS IAM. Also on my gripe list: Using raw JSON to specify policy rather than a better DSL for expressing complex logic. Trying to get certain conditions properly specified can be a mind bender with the syntax provided, or be downright impossible.

Hikikomori 4y ago
We use both. Have a managed project where people can create their own IAM roles using defined policies for all services. For some use cases creating your own role is better so they must attach one of the roles they create with the project as their boundary when they create the role.

danw1979 4y ago

This would be great advice, but until AWS have a more solid story about resource sharing (to avoid duplicated costs for your usual boilerplate account infra) then you’ll quite quickly end up amalgamating accounts to reduce costs again, in my experience. RAM is getting there, but I tried this pattern again recently and ran headfirst into the problem of not being able to easily share a R53 zone between accounts without it descending into a mess of assume-role. I’m sold on the simplicity of small team accounts rather than larger accounts with complicated IAM policy though.

Hikikomori 4y ago
Why not give each account and region its own zone?