Hey there! I'm looking for advice on how organizations effectively design and manage AWS IAM Identity Center (SSO) permission sets when scaling up. In our case, we map permission sets to Active Directory/Okta groups. Some of these groups are team-based and thus have access to multiple AWS accounts. This creates complications because team memberships change frequently and some users are part of multiple teams.
Since access is assigned at the group level, we face issues where granting access to one person inadvertently gives broader access to others in the same group who may not need it. We also receive numerous access change requests. While we aim to enforce least privilege, we're struggling to balance that goal with operational overhead and the risk of excessive permission sets.
I'm curious about how you folks structure your permission sets and groups to effectively scale without constant revisions. Do you utilize team-based, job-based, or hybrid permission sets? Do you create distinct groups for each account, team, and job role, or do you follow a different approach? For engineers, do you provide birthright access? If so, what does that entail, and does it differ between environments such as sandbox, non-prod, or prod? How do you assess what access a team really needs, especially when users aren't sure what permissions are appropriate? Additionally, how do you manage temporary access to a permission set? Lastly, who typically approves access to these permission set groups (is it the manager, app owner, platform, security, etc.)? I'd love to hear any real-world insights, lessons learned, or 'what not to do' anecdotes. Thanks!
3 Answers
The secret to effective IAM management lies in a well-defined RBAC structure. Start by clearly defining roles, identifying their necessary actions in different environments, and creating relevant permission sets. For instance, we established specific sets for Developers, Testers, DevOps, and Admins, each with tailored access based on their role. This way, users usually stay within their access boundaries, and any permission requests that fall outside that framework signal either a deficiency in our system or an attempt to bypass our model.
Managing IAM Identity Center on a large scale can be tricky. We've implemented a strategy where we lean into a combination of standard RBAC IAM permissions and group assignments. This helps us avoid permission set sprawl to a large extent. We have enterprise-wide console roles for most daily access requirements but account-specific permission sets for engineering teams that need more tailored access. Automation is key; we custom-coded a lot of our processes based on CloudTrail events from identity stores, and it's been effective so far. We're also planning on shifting towards an ABAC model to further streamline our permission sets in the future. If you need specifics, just ask!
When you say 'we,' do you mean a dedicated team for this? Given your size, does it include a mix of senior and junior staff?
We usually map our permission sets to job roles for each account, connecting each role to an AD group. Each AWS account has designated owners and a support group to identify what permissions are necessary for each role. When someone requests different access, we ask if we should create a new role for them or if it’s something everyone in that group should have. The owners are responsible for keeping track of these changes, especially during quarterly audits.
How many groups and accounts do you currently manage?
How many groups and accounts do you currently manage?