Customising AWS Control Tower with CfCT

If you missed the previous posts on Deploying a Landing Zone with AWS Control Tower or you’ve not had much experience with the service, we’d recommend reading Parts 1 to 3 before continuing.

• Part 1 - Deploying AWS Control Tower
• Part 2 - AWS Control Tower Post Configuration Tasks focusing on Organisational Structure and Guardrails
• Part 3 - AWS Control Tower Post Configuration Tasks focusing on IAM Identity Center and Provisioning New AWS Accounts

In this post, we’re going to walkthrough how you can start customising Control Tower using the Security Reference Architecture (SRA). The SRA utilises Customisations for Control Tower (CfCT) which deploys a DevOps pipeline that works with CloudFormation templates and Control Tower lifecycle events.

By no means is this the only way of customising the Landing Zone that Control Tower deploys, but it’s how the previous version of AWS Landing Zones was based upon and therefore, more users will be familiar with its setup and configuration. It does have some drawbacks though, in that it is only single threaded and therefore slow in large environments.

Here are some alternatives:

• Service Catalog Tools
• AWS Deployment Framework (ADF)
• Account Factory for Terraform

Why would I want to customise Control Tower?

The easiest way to answer this question is simply because whilst Control Tower provides the foundations for a Well-Architected Multi-Account Landing Zone, it’s not completely perfect.

In terms of AWS Services, Control Tower is still in its infancy and whilst AWS is constantly adding new functionality and guardrails, there are still some basic best practices that aren’t there natively. For example, in Part Three we mentioned that AWS Config doesn’t get configured in the Management Account but it is in every other Member AWS Account.

The reality is, there is no one size fits all, but there are synergies between them. With this in mind, the majority of organisations will need to tailor the Landing Zone to meet their specific security and governance requirements.

Enable Trusted Access for CloudFormation StackSets in AWS Organisations

If you already have Control Tower enabled for you, this next section might not be relevant. However, it’s always worth double checking just to play safe.

• Login to the AWS Management Console using an Account with administrative permissions and navigate to the AWS Organisations Console. This should be done within the Management Account.

• Click Services.

• Scroll down to CloudFormation StackSets and check that its Trusted Access is set to Access enabled. If not, then Click CloudFormation StackSets and then Click Enable trusted access.

Configure an AWS CLI Profile to the Management Account

• Establish an AWS CLI Profile to the Management Account with administrative credentials via the AWS CLI using either a Command Prompt or from Powershell:

• In the SSO start URL, type the URL of the SSO Login page. For example., https://d-1234567890.awsapps.com/start This can be found by logging into the IAM Identity Center Console and looking for the AWS access portal URL in the Settings.
• In the SSO Region, type the AWS Region that was used for the Home Region when deploying Control Tower. For example., eu-west-2

A web browser will then open prompting for login credentials if you’re not already logged in.

• Login with your Username and Password.
• Click Allow.
• Select the AWS Management Account using the cursor keys.
• Press Return for the default client Region and the default output format.
• For the Profile name use something memorable as this can be anything. For example., ct-mgmt

Deploying the SRA Common Pre-Requisites

There are a few things that need to be installed on our local device as a pre-cursor for this part, including Git, Bash Shell, the AWS CLI v2 and 7-Zip. The following instructions will be based on running a Windows Device.

• Clone the SRA Source Files from GitHub via either a Command Prompt or from Powershell:

Now that we have the SRA source files locally, we need to start creating some CloudFormation Stacks in our Management Account using the YAML templates within the source. These templates setup the functionality for SRA to work before we even install the Customisations for Control Tower solution.

• Launch the sra-common-prerequisites-staging-s3-bucket.yaml via the AWS CLI using either a Command Prompt or from Powershell:

• Package and upload all the SRA Solutions to the Staging S3 Bucket via GitBash:

• Launch the sra-common-prerequisites-management-account-parameters.yaml via the AWS CLI using either a Command Prompt or from Powershell:

• Launch the sra-common-prerequisites-main-ssm.yaml via the AWS CLI using either a Command Prompt or from Powershell:

Deploy the Customisations for Control Tower Solution

The team at AWS has developed the SRA utilised Customisations for Control Tower (CfCT) as the delivery mechanism for their customisations. But since they don’t maintain that solution itself, it’s strongly recommended to check the current version of CfCT here prior to launching the CloudFormation Template.

You may find that you wish to edit sra-common-cfct-setup-main.yaml to reflect the following change instead:

The architecture that is deployed by CfCT is shown below.

• Launch the sra-common-cfct-setup-main.yaml via the AWS CLI using either a Command Prompt or from Powershell:

What Customisations should I make?

This is always very subjective and there are many things that may factor into the answer. That being said, here are a few suggestions, in no particular order! And best of all, they are all included within the SRA Source Files with the exceptions of the Service Control Policies (SCPs). There are also other CloudFormation Templates available within the SRA source files that could be used, or alternatively, you may wish to create your own.

CloudFormation

• Enable Config in the Management Account
• Enable CloudTrail Organisational Trail for Data Events
• Enable EC2 Default EBS Encryption
• Configure a Hardened IAM Account Password Policy
• Enable S3 Block Public Access at the Account Level
• Configure AWS Account Alternate Contacts
• Enable IAM Access Analyzer and Configure for Delegated Administration
• Enable GuardDuty and Configure for Delegated Administration
• Enable Macie and Configure for Delegated Administration
• Enable Security Hub and Configure for Delegated Administration

Service Control Policies

• Prevent Accounts from Leaving the Organisation
• Prevent the Disabling of any Security Tooling
• Prevent IAM User Creation

Time to Customise our Control Tower Setup

This section will go through customising Control Tower based on the author’s personal recommendations.

• Install the git-remote-codecommit module via either a Command Prompt or Powershell.

• Clone the CodeCommit repository that is deployed by CfCT via either a Command Prompt or Powershell.

Note: You’ll need to ensure that you use the name of your AWS CLI profile prior to the @ as shown in the example above.

• Within your IDE of choice, under the custom-control-tower-configuration folder, delete the example-configuration folder.
• Under the custom-control-tower-configuration folder, create three new folders named parameters, policies and templates.

• Copy the following files from the SRA source files to custom-control-tower-configuration\templates.
  • sra-account-alternate-contacts-main-ssm.yaml
  • sra-cloudtrail-org-main-ssm.yaml
  • sra-config-management-account-main-ssm.yaml
  • sra-ec2-default-ebs-encryption-main-ssm.yaml
  • sra-guardduty-org-main-ssm.yaml
  • sra-iam-access-analyzer-main-ssm.yaml
  • sra-iam-password-policy-main-ssm.yaml
  • sra-macie-org-main-ssm.yaml
  • sra-securityhub-org-main-ssm.yaml
• Copy the following files from the SRA source files to custom-control-tower-configuration\parameters.
  • sra-account-alternate-contacts-main-ssm.json
  • sra-cloudtrail-org-main-ssm.json
  • sra-config-management-account-main-ssm.json
  • sra-ec2-default-ebs-encryption-main-ssm.json
  • sra-guardduty-org-main-ssm.json
  • sra-iam-access-analyzer-main-ssm.json
  • sra-iam-password-policy-main-ssm.json
  • sra-macie-org-main-ssm.json
  • sra-s3-block-account-public-access-main-ssm.json
  • sra-securityhub-org-main-ssm.json
• Amend the values as required in each of the JSON files above to customise the configuration of each of the different templates. For example., IAM Password Policy configuration will be defined in the sra-iam-password-policy-main-ssm.json.

• Create scp-prevent-accounts-leaving-org.json in custom-control-tower-configuration\policies and paste in the below contents.

• Create scp-prevent-disabling-security-tooling.json in custom-control-tower-configuration\policies and paste in the below contents.

• Create scp-prevent-disabling-security-tooling.json in custom-control-tower-configuration\policies and paste in the below contents.

• Create scp-prevent-iam-users-creation.json in custom-control-tower-configuration\policies and paste in the below contents.

• Modify the contents of manifest.yaml as per below.

• Commit the files that you’ve previously copied, modified and deleted to CodeCommit via either a Command Prompt or Powershell.

This will now trigger the DevOps Pipeline and, assuming that no issues have occurred, will show as Succeeded.

This is the end of our AWS Control Tower part four series. We hope it proved useful and enables you to customise your own Control Tower Environments.

Should you have any additional questions around cloud security governance, or comments in general, we’d love to hear from you. Drop us a message and the team will be in touch to arrange a follow-up call.

About the author:

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.