I'm looking for insights into how different organizations structure and manage AWS IAM Identity Center (SSO) permission sets efficiently at a large scale. Our setup involves mapping permission sets to AD/Okta groups, and we face challenges due to group-based access which can lead to unnecessary broader access for users who don't need it. Additionally, the frequency of team changes complicates things further. We're aiming to enforce least privilege while minimizing operational overhead and managing permission set sprawl. I'd love to hear how you structure permission sets and groups to manage this effectively, whether you use team-based, job-based, or hybrid models, and how you handle access requests, especially temporary ones. Insights from your real-world experiences, including patterns or lessons learned, would be greatly appreciated!
3 Answers
We generally map permission sets to job roles for each account, linked to AD groups. Each AWS account has designated owners to specify what roles require what permissions. If someone needs access beyond their role, we evaluate whether to create a new role or adjust the existing group. It's essential for these account owners to manage user access audits regularly, ensuring everything stays organized.
Establishing a solid RBAC structure is fundamental. We define roles and necessary permissions for various environments, rolling them out as PermissionSets. For example, developers get almost full access in Dev but only limited read access in Prod. This clear separation encourages compliance with the operating model and helps identify when access requests might indicate gaps in that model.
Sounds structured! What’s your current management scale in terms of groups and accounts?
In my experience with a large setup (around 15,000 users and 400 AWS accounts), I've found that a combined approach of Identity Center and standard RBAC IAM permissions leads to permission set sprawl, which is inevitable. We primarily use enterprise-wide console roles for daily needs, but allow for account-specific permission sets to cater to specialized access. Custom automation based on CloudTrail events has been key to managing this effectively, and we are moving toward an Attribute-Based Access Control (ABAC) model to further reduce the number of sets we need. Feel free to ask more specific questions if you have them!
Do you have a dedicated team for managing this at such a large scale? Sounds like you have quite the operation!
How many groups and accounts are you currently overseeing? It sounds like a complex setup!