A brief context
- This project concerns a large multi-cloud customer: more than 10,000 employees
- Who has an AWS landing-zone automation: 30 -> 600 AWS accounts in 3 years
- And several AWS Organizations
- Manage AWS console access for projects on their dedicated AWS accounts
Cross-functional access and IAC remain on the Identity model seen in part 1/3, so as not to overload AWS IAM Identity Center, which has API limits to consider.
- Implement security: corporated MFA and source IP restriction
- Be scalable: up to 10,000 users
- Manage segmentation between multi AWS organizations
- With Azure Active Directory as IDP
Binding AAD Groups to AWS SSO Assignments
- Azure Active Directory
Azure Active Directory is the referential directory. It is defined as the AWS SSO Identity Provider for each AWS Organization.
In AAD, an Administrative Unit has been dedicated to the solution in wich we manipulate groups, owners and SSO members.
It is connected to AWS through Enterprises Applications.
- Enterprise Application
These are Applications on Azure supported by AWS that allow you to link providers with AWS SSO.
There are 1 per AWS Organization
- App Registration
These are Azure records of applications carrying Applications rights.
There are 3:
And IAC_PROD for IAC accesses in Graph API
Points of attention
AWS access are now managed by a cross clouder process, chaining Azure AD actions and AWS SSO calls. Somes buffers are needed in these processes and all steps must be resilients and idempotents.
The expected payload is between 500 and 2000 AWS Accounts.
The customer’s landing zone factory delivers 5 default roles per AWS account with an average of 20 AWS accounts per mounth.
-> solution must handle multiples roles creation at the same time.
IAC on Azure
Using Graph API with an App Registration owner of each Azure Enterprise Application for SSO
AWS SSO Observability
- MS Teams flux is used to follow live role creation progress.
Default accesses creation on 1 AWS account:
Alien SSO configuration detected:
- A ‘live SSO state’ is maintained in dynamodb that compiles configured and real SSO accesses.
SSO Access State can be graphed dynamically:
By controlling ‘who do what’ in AWS SSO, the automation can therefore ingests console SSO configurations as well.
There are 2 differents types of AWS SSO actions in CloudTrail:
- SSO users actions: authenticate, federate …
- SSO configuration actions: account assignment, permissionset creation …
All SSO actions are audited, both those coming from factories and those coming from outside the factories.
Complete SSO Observability is provided by the project SAS ( SSO Access State )
-> SAS Project will have its own article.
After survey and architecture, automation of SSO accesses will be discussed in section 3/3 of this story.
The following topics will be covered:
- Global automation process
- Azure resource availability in IAC
- Azure<->AWS synchronization limit
- AWS SSO assignment control
Paul Boucher, Team Leader AWS