Technology Capabilities
Technology CapabilitiesGlobalLogic provides unique experience and expertise at the intersection of data, design, and engineering.
Get in touchIn this post, we’re going to walkthrough some of the remaining post configuration tasks including configuring IAM Identity Center and provisioning a new AWS Account through Account Factory.
AWS IAM Identity Center (formerly known as AWS SSO) is a service that enables you to have a single point of entry for managing resources within all of your AWS Accounts in an organisation.
As part of the Control Tower deployment this gets enabled using the native Identity Center directory. This allows you to create Users, Groups and Permission Sets that, when assigned to an AWS Account, would allow you to authenticate and have authorisation to different resources based on the policies defined in the Permission Set. Whilst the Identity Center directory is the default configuration, a post deployment activity is typically to change this to either a 3rd Party Identity Provider such as Azure Active Directory or to perhaps an on-premise Active Directory Domain (AAD).
For those without access to an Azure Active Directory Domain, please refer to the instructions below:
When IAM Identity Center is integrated with a 3rd Party Solution such as AAD, you add your AAD Groups to the Azure Enterprise Application. As part of the System for Cross-domain Identity Provisioning (SCIM), Groups and the Users that are member of those Groups will be replicated and created within IAM Identity Center. This provides the user the ability to login through the AWS access portal URL and authenticate using their standard login details – those used for other business workloads such as email etc.
Since all the identity management is now connected to the corporate AAD, things such as password policies are handled by AAD. However, Multi Factor Authentication (MFA) could be handled either by AAD or alternatively, you may decide to handle that within IAM Identity Center.
As a best practice, permissions should follow the principle of least privilege access. An enabler of this is through the use of Permission Sets with IAM Identity Center. There are several default Permission Sets created by Control Tower, although these don’t always meet all requirements.
Behind the scenes, once you’ve created a Permission Set and you’ve assigned it to the AWS Account(s) that you want that applied to and the Groups you want to associate, an IAM Role is created hwhich has a Trust policy configured to only allow the role to be assumed using SAML and it must have come via the IAM Identity Provider within that Account which was also created by IAM Identity Center.
Depending on what you’re trying to achieve from a permissions allocation perspective, you might attach different types of policies or a combination of them all. This could include AWS Managed Policies, Customer Managed Policies, Inline Policies and or Permissions Boundaries. In this example, we’re going to show examples of using just an AWS Managed Policy as we only want to give S3 Full Access to people via SSO.
The next time the user authenticates through Single Sign-On they’ll be able to leverage the new permissions as they’ll see another role available to them.
One of the capabilities that Control Tower provides is the Account Factory. Account Factory is used for provisioning new AWS Accounts that will in turn be governed via Control Tower and configured with all the baselines that Control Tower will provide, such as CloudTrail, Config, CloudWatch as well as guardrails.
The Account Factory provides the ability to create a VPC as part of the Account provisioning. A key challenge of this functionality is that the Network configuration is controlled within the Control Tower Console. This configuration means you must choose whether you have Public Subnets and/or Private Subnets and you can only have a maximum of 2 Private Subnets per Availability Zone and deployed based on a Well-Architected design. One of the configuration choices is the CIDR range that you select for the entire VPC, but you have no option as to how this is then utilised for the Subnets; it’s simply split evenly across them all. Another is the region(s) that this same VPC configuration is implemented in, which is determined by the regions that are governed by Control Tower. In situations where you have multiple regions that require VPCs and the Account is provisioned via the Account Factory, this goes against best practice since you end up with overlapping CIDR ranges which would cause network routing issues should these VPCs need to communicate with each other.
With this in mind, we would recommend disabling this functionality in the Account Factory, by unchecking any regions in the Account Factory Network Configuration. This can be done by:
Once the AWS Account has been fully provisioned the Account will show as Governed within the Control Tower console.
That’s all for the basic configuration of AWS Control Tower. In an upcoming post, we’ll walkthrough how you can customise Control Tower.
Adam Divall, Solutions Architect at GlobalLogic with over 20 years demonstrable experience in design, implementation, migration and support of large, complex solutions to support a customer’s long term business strategy. Divall holds all 12 available certifications for Amazon Web Services with specialisations including Networking, Security, Database, Data Analytics and Machine Learning.