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
- Automation with Finops and Devops mindset
Solution must provide:
- End-to-end AWS access management, from AD user to AWS account
- Project autonomy on owners, members and policies of their project roles
SSO console access configuration for projects are stored in Codecommit repo and ordered at role level. Each role configuration identifies its owners, permissionset and targeted AWS account(s).
Steps identified to provide AWS console access to customer user
- Create AAD Groups
- Synchronize AAD Groups with AWS SSO Groups
- Manage AWS SSO permissionset
- Assign AWS Accounts access
Points of Attention
Each Clouder has its own API management, with its definitions and limits.
Various buffering methods had to be implemented in the solution to support full resiliency.
Rolator applies the AWS permissions and accesses defined by customer.
It unifies configurations between the Identity Provider (AAD) and AWS IAM Identity Center (AWS SSO).
Rolator is a Stepfunction bringing together all the necessary steps for creating AWS access with 2 guidelines:
- Independence: multiple Rolators can be executed at the same time.
- Idempotence: the steps can be replayed as many times as you want, this will only create what is requested.
However, ‘force=yes’ parameters are availables to be able to reset configurations if necessary.
Lambda activating the differents stages of Rolator depending on events.
- Creating default roles for an AWS account
- Creating a specific role
- Modifying role permissions
- Changing a role’s access to AWS accounts
SSO Group Management
Stepfunction managing groups and owners in AAD, and synchronization with AWS.
- Creating groups in AAD
In Azure, newly created group availability randomly depends on AAD built-in replication: a new AAD group can be successfully created, the new group id can be unknown from Enterprise Application inventory at this time.
A waiting buffer has been implemented by scanning group’s owner definition: if this parameter is up to date, all is up to date.
- Definition of group’s owners in AAD ( force = yes available)
- Deleting groups in AAD
- Sync AAD Groups in AWS SSO
An Azure global limitation of ‘5 max sync starts every 10s’ is addressed by a centralized sync buffer system
SSO PermissionsSet Management
Stepfunction handling permissionsets in AWS SSO
PermissionSets are sets of rights availables in SSO and which can be made up of different IAM policies:
- CustomerManaged: these must be present in the target AWS account
❗ only CustomerManaged policies can be delegated to project ❗
It is in the permissionset that we define the user’s session duration, set at 4 hours by default.
- Creating default permissionsets: default-arch, default-ops, default-dev, default-bil, default-prj
- Creation of specific permissionsets
- Deployment of CustomerManaged Policies in dedicated AWS accounts (force = yes available)
- Deployment of permissionset updates
SSO Assignment Management
Stepfunction assigning SSO access to AWS accounts
- Configuring SSO access: loop on ‘Configure access to 1 AWS account for 1 group with 1 or more permissionsets’
A limitation of ’10 running assignments max / AWS organization’ is addressed by map’s concurrency limitation in Stepfunction.
Customer gains full control and granularity of his AWS console accesses, and can welcome all new project on AWS with serenity and security.
And the solution is highly resilient et observable.
Cost evaluation is around 5 $/m.
Fun fact: EFS mounted on lambda for sync buffering solution between Azure and AWS, is evaluated to … 0$, while being over-utilized for development purposes in August 🤩
Eager to test in live, Rolator’s first steps will grow between 10/2023 and 04/2024.
Let me know if you are interested by some deep-dives or maybe following its evolution.
Paul Boucher, Team Leader AWS