Hi everyone

This blog article came out of a recent problem that I had to solve in my own architecture deployment for Datacom. This is the first blog article written on Control Tower but it wont be the last. I will be delving into how Control Tower and Organisation Governance improvements can greatly improve a hub and spoke security posture and make compliance easier.

But for now I am focused on the initial set up of the landing Zone.

What is a landing zone?

 In AWS Speak and Datacom Speak a landing zone is really a Governance strategy for multiple AWS Accounts with a centralised model and focus. AWS Accounts are not their own little silos anymore and AWS Encourage a multi account strategy. And by Introducing Control Tower they have made that a substantial amount easier.

Requirements for setting up a landing zone:

If you have just set up a brand new AWS Account and want to turn it into your Master Account for Organisations and Control Tower then you wont really have an issue. However if you have an existing Organisation Master Account and want to overlay Control Tower on to it then the below requirements are important:

• Stop and Delete any existing AWS Config Recorders in ALL Regions
  • This is required for any AWS Account within the Organisation that you want to enrol in Control Tower
  • Any delivery channels must also be deleted
• Root E-mail addresses available for Security and Log Archive Accounts (2 Accounts are created by Control Tower Setup for Base functionality)
• AWS Single Sign On (if it is ALREADY deployed) must be in the same region as the Control Tower Home Region that is setup in the landing zone
• AWS Config and Cloudtrail cannot be enabled for Trusted Access in the Organisation
• Delete any existing Cloudtrail (after deployment) or else duplicate Cloudtrail charges will occur. Control Tower enables Cloudtrail and leverages the Log Archive s3 bucket for its data)
• Create a Customer Master Key for the Control Tower Encryption of Cloudtrail and services (Optional for AWS Control Tower but highly recommended by me). See below for a KMS Key Policy that will work with Control Tower.
  • Key must be Symmetric and located in the same region as Control Tower Home Region.
  • It requires access to AWS Config and Cloudtrail Services

 Setting up a Control Tower Acceptable KMS CMK

This is really the point of this blog. When I first started investigating using a CMK (which was only recently added in to version 2.7 of Control Tower. See this AWS Article) I failed to deploy because the CMK required a specific set of policies applied. I solved that problem in my environment but then I went back and thought about how to do it in Cloudformation and with Automation. See the bottom of this blog post for a link to a Cloudformation template I put in github.

AWS Control Tower doesnt support automatically creating a key with appropriate policies during landing zone setup. It does support creating one by clicking on a link within but you need to ensure the appropriate key policy is defined. If you create a key from within the landing zone setup you then need to edit the Key Policy and add the following within the Key’s policy statement.

I will show below a step by step approach to creating the Key in KMS from the Management Console. The Cloudformation template will be at the bottom of this article in the Reference section.

 1. Login to the AWS Management Console and select Key Management Service. Click on Customer Managed Keys and then create key.

This requires that the logged in user has appropriate permissions to KMS. For simplicity it is assumed by me that the person following this has administrative access to the account.

Ensure that the Region is the same region that Control Tower is going to be deployed to as a home region.

On the Next Screen you can leave most of it as default but I will just note:

• AWS Control Tower does not support Multi Region Keys so the Key must be Single Region
• AWS Control Tower does not support asymmetric keys so ensure that the key is defined as symmetric.

Click Next

On the Next Screen you Give your key a name (which will act as Alias for visual reference) and description. Add tags if desired and click Next.

Changing Administrative Permissions is not required so click Next.

Changing Key Use Permissions in this screen is not necessary. Click Next (we will insert key policy statement on the next screen)

On the Review Screen you can insert the below Json Code into the Key policy as shown in the screenshot. Add a , after the } before the closing ] so that you can create a new permission in the statement.

After you have finished it is recommended that you enable Key Rotation for the Key. You do this by clicking onAccessing the key you just created in the Key Management Service Console and selecting the Key Rotation Tab. Tick the Checkbox and then click save as per below. After that you are done with the Key and can go ahead and create the landing zone.

Landing Zone Setup

Now we have the Key and everything is good lets return to Control Tower. Set up the Landing zone from the Control Tower Option in the Management console.

There is currently no API support to deploy a landing zone by cli or code but I hope that AWS will introduce it in a future version as that would be perfect for our Automated Landing zone as a Service (Datacom have built a great landing zone as a service using Control Tower in internal testing at the moment for our customers to come soon).

 When you access the Control Tower console click Set Up Landing Zone

On the First Screen you define the home region. This should be the region where most of your workload resides. It also needs to be the region AWS SSO is deployed in if it exists in the Organisation already.

You can choose to Govern other regions. This will add cost but can provide coverage for any resources that might be installed elsewhere. Click Next on the below screen when you have added any regions you want to govern beyond the home region.

Next you define the Standard OUs. AWS Control Tower creates 2 accounts that reside in the Security OU (Used to be called Core). You can change the name but its not recommended. You can define an additional OU where you can define workloads. This can be defined after completion.

I mentioned earlier that you need 2 additional email addresses for AWS account root emails. This next section is where you define the accounts.

You create a Log Archive Account and an account for Security. The default name is “Audit” which I am not overly fond of so I tend to rename it to Security or Security Governance. Its function is for Security Engineers to be able to interact with other accounts. We also use it as master account for Security services like Guard Duty and Security Hub (deployed in our environments after Control Tower is Setup).

On this screen you also define the KMS Key to use for Encryption and you do so by clicking Enable on the bottom of the screen and selecting the CMK created earlier.

Click Next after everything is defined

On the Review Section you check everything and then tick the box acknowledging that Control Tower setup will create resources and then click the Setup Landing zone button to setup.

After you click the button to setup it will take up to 60 minutes to complete account setup and deployment of Guard Rails. After that is done you have a landing zone that you can build off

and voila… a Control Tower environment with centralised User login via AWS Single Sign On and the ability to provision new accounts and go.

but dont stop there. You really need to just use Control Tower as a Springboard. Tie it with other AWS Services such as Transit Gateway, AWS Backup and Security Hub. And Part of my job is building this sort of architecture for customers so you can come and see us at Datacom

Reference: CMK with Control Tower Requirements Cloudformation Template