Overview
Federated Access is a must for any organization with more than one AWS account and many companies are already using Azure Entra to federate access other places and are synced from on-prem AD servers. This post points to guides on how to establish trust and sync users, and then most importantly how to manage permission set and account assignment on the AWS side.
Sync Setup
This part is very well documented here: https://docs.aws.amazon.com/singlesignon/latest/userguide/idp-microsoft-entra.html
At the end of that tutorial you’ll have set up infrastructure that looks vaguely like this:
When you assign users or groups to the Enterprise Application they will sync across to IAM Identity Center.
IAM Identity Center Basics
There are three basic entities we’ll deal with in IAM Identity Center
- Users and Groups
- These are Identities and groups of identities that are authenticated with your IAM Identity Center instance.
- Permission Sets
- The policy documents for permission sets are contained in either AWS Managed Policies, Inline Policies, or Customer Managed Policies.
- Managed policies are easy but offer very broadly scoped roles for many things.
- Customer managed policies are referenced by name, and must be deployed to each account by you (great use case for StackSets. See my other post HERE)
- Inline Policies, which deploy automatically to the accounts you assign the permission set to, but can’t scope statements down to resources very well as there is no templating language for specifying a ‘this account’ account ID in the resource ARNs
- AWS Accounts
- Accounts in your Organization.
Users or groups are assigned to an account with a permission set (1:1:1). You cannot assign a group to an OU with a permission set unfortunately, but there are some easy CDK tricks to getting around that.
In the end you’ll end up with something that looks like this:
Mark this is really basic shit, why are you writing a blog post about it?
So glad you asked. The assigning of Groups to Permission Sets to Accounts is manually done in your Management account via the console. That sucks.
The green circle above indicates the area of pain. This area is critical to the security of your organization and should be controlled in code and pipeline in a way that is easy to read and modify via PR. An obvious candidate for that is an AWS CDK Self-Mutating pipeline.
A CDK Pipeline (L3 Construct) would allow for a couple really obvious advantages including being self contained in the management account, and the ability to use much nicer variables for the accounts, permission sets, and federated groups/users than the ID’s (currently required by cloudformation).
For all that goodness, go to the next post: https://polarops.ca/2024/12/07/automating-iam-identity-center-permission-sets-and-assignments/
