AWS Cloud Operations Blog

Extend AWS Control Tower governance using AWS Config Conformance Packs

As many customers adopt AWS Control Tower, they have asked Raphael and me how to add additional governance policies such as the NIST Cybersecurity Framework (CSF) to their environments on top of the guardrails that AWS Control Tower provides. Customers want to enable these additional policies on the AWS Regions where AWS Control Tower is available and also on the other AWS Regions. In the rest of this post, we will call the AWS Regions, where AWS Control Tower is available “AWS Control Tower Regions.” In this post, we will show you how to achieve this.

AWS Control Tower uses AWS Config to implement detective guardrails. AWS Control Tower automatically enables AWS Config in the AWS Control Tower Regions, with configuration history and snapshots delivered to an Amazon S3 bucket located in a centralized Log Archive account.

AWS Config Conformance Packs enable you to create packages of compliance rules, simplifying deployment at scale by packaging up both rules and remediation actions into a single entity. Conformance packs rely on AWS Config recording being enabled in a Region, as compliance is reported based on tracking resources and changes to them.

Customers can start deploying AWS Control Tower in one of its Regions and enable the baselines and guardrails included within the service. Independently, you can then enable multiple additional AWS Config Conformance Packs on AWS Control Tower Regions or the remaining AWS Regions. With this approach, you can take advantage of the well-architected landing zone and best-practice blueprints. You can also enable governance using guardrails that come with AWS Control Tower and apply additional governance using other AWS services.

AWS Control Tower uses AWS CloudFormation StackSets to create resources like AWS Config Aggregator, AWS CloudTrail and centralized logging. In this post, we leverage the same mechanism to enable AWS Config in other Regions. Then we follow the instructions outlined in the Deploy AWS Config Rules and Conformance Packs using a delegated admin post to enable guardrails across the organization.

There are two main advantages of following the guidance provided in this post:

  1. There is no need to move the history of your AWS Config data between buckets when AWS Control Tower launches a new AWS Region. You will continue to maintain the AWS Config history in the same S3 bucket created by AWS Control Tower.
  2. You can continue to use the AWS Config Aggregator set up by AWS Control Tower to visualize and audit your entire environment from a single location.

Here’s a quick review of some of the terms used in this post:

  • An AWS Account Factory account is an AWS account provisioned using Account Factory in AWS Control Tower.
  • AWS Control Tower home Region is the AWS Region where your AWS Control Tower was deployed.
  • AWS Service Catalog allows you to centrally manage commonly deployed IT services. In the context of this blog post, Account Factory uses AWS Service Catalog to provision new AWS accounts.
  • AWS Organizations helps you centrally govern your environment as you grow and scale your workloads on AWS.
  • AWS CloudFormation StackSets extends the functionality of stacks by enabling you to create, update, or delete stacks across multiple accounts and Regions with a single operation.
  • A stack instance is a reference to a stack in a target account within a Region.
  • A stack is a collection of AWS resources that you can manage as a single unit.
  • An Aggregator is an AWS Config resource type that collects AWS Config configuration and compliance data from multiple accounts and Regions with in the organization.
  • A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity in an account and a Region or across an organization in AWS Organizations.
  • AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data management and secrets management.

Things to consider

Below are some of the exceptions that are essential to understand before we dive deep in to the solution:

  • As part of this post, you will deploy Stack instances in additional Regions and orchestrate this through a custom AWS Cloud Formation StackSet. When AWS Control Tower is available in a new Region, customers get notification to update the AWS Control Tower.
  • Before you update AWS Control Tower, you need to delete the stack instances for these newly supported Regions with in the custom AWS Cloud Formation StackSet. Required steps are mentioned later.
  • If you fail to delete the stack instances before upgrading AWS Control Tower, the AWS Control Tower update process could fail.
  • During the time period in which you delete the Stack instances and upgrade AWS Control Tower, the traceability of any configuration changes will not be captured. It is recommended to perform the deletion of stack instances and upgrading at time window where minimum changes to your resource configuration are expected.
  • Once the AWS Control Tower Landing Zone is upgraded successfully, you will have the continuity of the AWS Config data, which is collected in the centralized log archive account.
  • AWS CloudFormation StackSets are yet to be supported in few Regions, such as eu-south-1, me-south-1 and af-south-1. You cannot use this solution for those Regions using the steps provided in the post. For latest information on supported Regions for AWS CloudFormation StackSets, refer to Global infrastructure Region table.
  • In case AWS Config was ever enabled in the other Regions, a default Configuration Recorder and Delivery channel are created. These must be removed from the account and Region to which you are going to extend governance. Check Failure Error that Mentions AWS Config for steps to achieve this.

The source code for this solution is available here.

Solution Overview

The following diagram illustrates the steps involved in enabling AWS Config and detective guardrails in the Regions in which AWS Control Tower is not yet supported.

You need to deploy the CloudFormation stack in the AWS Control Tower home Region. When you deploy the CloudFormation stack provided as part of this blog post, it deploys following:

  1. Creates a Lambda function that:
    • a) Queries the existing AWSControlTowerBP-BASELINE-CONFIG StackSet for template body and parameters that AWS Control Tower uses to configure AWS Config on the Regions that AWS Control tower is supported on.
    • b) Stores the list of regions RegionsToDeploy in Parameter Store.
    • c) Creates a new StackSet in the main account with template body and parameters derived from step 1a. This new StackSet will be used to deploy AWS Config resources across other Regions.
    • d) If SetupConformancePack is selected while deploying the stack, an additional stackset will be deployed in the log archive account to configure the S3 bucket that is required for conformance packs.
    • e) Creates an S3 bucket and applies bucket policy to enable GetObject and PutObject access to all accounts with in the organization.
  2. Sets up the lifecycle event trigger to automatically enable Config when new accounts are created using Account Factory.

Refer to the following architecture diagram.

Enable AWS Config in AWS Control Tower

When a new account is created using Account Factory:

  1. AWS Control Tower generates a CreateManagedAccount lifecycle event.
  2. When this event is generated, an Amazon CloudWatch rule adds the event to Amazon Simple Queue Service (Amazon SQS) queue.
  3. Amazon SQS queue triggers a Lambda function in the order it received.
  4. Lambda function process the event for account-id and:
    • a) Gets Regions list for the SSM Parameter Store
    • b) Adds a stack instance to the existing StackSet.
  5. Enables AWS Config and adds the selected Regions to Config Aggregator in the Audit account. Refer to the following architecture diagram.

Using Life cycle events to configure AWS Config on new AWS Accounts.

Follow the steps provided in this blog post to enable delegated admin access to the AWS Config Aggregator and to enable the conformance pack across the organization.

Note: Use the latest aws-cli version.

How it works

Step 1: Launch Config baseline stacks across account/Region(s)

We launch a stack that creates new StackSet to enable AWS Config, add to Config Aggregator, and configure centralized logging in other regions. In addition, it optionally creates an S3 bucket in the Log Archive account, which is a prerequisite for conformance pack.

  • Log in to the AWS Control Tower main account and switch to your AWS Control Tower home Region.
  • Choose Launch stack.
  • Choose Next.
  • Fill in the parameters:
    • AWS Config Parameters
      • DeployTo:
        • Existing Only: Enable Config only on the new accounts. No lifecycle event triggers will be set up.
        • Future Only: Do not Enable Config on existing account. Set up lifecycle event triggers only.
        • Both (default): Enables Config on both existing accounts and set up lifecycle event triggers.
      • NewStackSetName: StackSet Name to be used for the new StackSet. Default: CUSTOM-CONFIG-STACKSET.
      • RegionsToDeploy:
        • Comma separated Region list. Default: “us-west-1,ap-northeast-1”.
  • Conformance Pack Parameters:
    • SetupConformancePack: Do you want set up infrastructure required for Conformance Packs, Yes (default) or no.
    • SSEAlgorithm: S3 encryption to be used, AES256 (default) or aws:kms.
    • KMSMasterKeyID: If using KMS encryption, the Key ID to be used.
    • LogArchiveAccountId: Account ID to be used for the Conformance Pack S3 Bucket. On AWS Control Tower main account, copy and paste the following URL and choose Log archive account to get the account id.
      • URL: https://console.thinkwithwp.com/controltower/home/sharedresources/logarchive

For this walk through, enter your AWS Control Tower Log Archive Account ID in LogArchiveAccountId and leave defaults for the other parameters.

    • Choose Next, Next.
    • Checkbox I acknowledge that AWS CloudFormation might create IAM resources and choose Create stack.
    • Wait until the Stack status changes to CREATE_COMPLETE.

In the CloudFormation StackSet name you provided in NewStackSetName earlier, check the Status of the Stack instances (should be CURRENT).

Step 2: Check for AWS Config and AWS Config Aggregator status

You have now enabled AWS Config in the additional Regions and added to Config Aggregator. Now, you must validate that the AWS Config status is properly reported on the AWS Config Aggregator. Sometimes it could take over 30 minutes for all these Regions to renegotiate the source status. The following aws-cli command allows you to view the overall status for various accounts and Regions.

  • Access the Audit Account using the AWS CLI
  • Check if AWS Config Aggregator successfully negotiated with the Regions in which the stack instances are deployed. For this example, check us-west-1, ap-northeast-1:
export CTHOME='<Your-CT-HOME-REGION>'
aws configservice describe-configuration-aggregator-sources-status --configuration-aggregator-name aws-controltower-GuardrailsComplianceAggregator --region $CTHOME --query 'AggregatedSourceStatusList[?AwsRegion==`us-west-1` || AwsRegion==`ap-northeast-1`].{SID:SourceId,Region:AwsRegion,Status:LastUpdateStatus,MSG:LastErrorMessage}' --output table
---------------------------------------------------------
|     DescribeConfigurationAggregatorSourcesStatus      |
+------+------------------+----------------+------------+
|  MSG |     Region       |      SID       |  Status    |
+------+------------------+----------------+------------+
|  None|  ap-northeast-1  |  965183582051  |  SUCCEEDED |
|  None|  us-west-1       |  300540541484  |  SUCCEEDED |
|  None|  ap-northeast-1  |  408161965614  |  SUCCEEDED |
|  None|  us-west-1       |  965183582051  |  SUCCEEDED |
|  None|  us-west-1       |  737250105869  |  SUCCEEDED |
|  None|  ap-northeast-1  |  959378824637  |  SUCCEEDED |
|  None|  ap-northeast-1  |  300540541484  |  SUCCEEDED |
|  None|  ap-northeast-1  |  737250105869  |  SUCCEEDED |
|  None|  us-west-1       |  408161965614  |  SUCCEEDED |
|  None|  us-west-1       |  959378824637  |  SUCCEEDED |
+------+------------------+----------------+------------+
  • Wait for all Regions to transition to a SUCCEEDED state. Then check in the AWS Config Aggregator for resources and any non-compliance on these accounts/Regions. This could take 15-20 minutes on an average.
  • Navigate to AWS Config Console, Aggregate view on the Audit account to view all non-compliance accounts or resources across your organization.

Step 3: Deploy AWS Control Tower Detective Guardrails using AWS Config Conformance Pack

You can enable the AWS Control Tower detective guardrails across all accounts by deploying the AWS Control Tower Detective Guardrails Conformance Pack. Deploy the conformance pack using one of two methods:

  1. Launch the conformance pack on an individual account,
  2. Enable conformance pack at the organization level.

We will use the second in this post. This option gives you the ability to enable guardrails and config rules across all your accounts with in the organization by executing a single command. You could also exclude enabling guardrails on few accounts from your organization if needed.

Follow the instructions detailed in Deploy AWS Config Rules and Conformance Packs using a delegated admin. The following steps are most relevant:

  • Run this command from the main account (update aws-cli to latest version if you haven’t yet done so)
aws organizations enable-aws-service-access --service-principal=config-multiaccountsetup.amazonaws.com
  • To check the status, run the following command and check for "ServicePrincipal": "config-multiaccountsetup.amazonaws.com" under “EnabledServicePrincipals”
aws organizations list-aws-service-access-for-organization
  • Register a delegated administrator account. Replace the {Audit-Account-ID} with your audit account id.
aws organizations register-delegated-administrator --service-principal=config-multiaccountsetup.amazonaws.com --account-id="{Audit-Account-ID}"
  • To check status of delegated administrators. Check for Id and Status sections of the output of below command.
aws organizations list-delegated-administrators
  • Download the AWS Control Tower Guardrails conformance pack to your local machine. You need it while deploying the conformance pack
  • If you have selected SetupConformancePack: Yes while deploying stack in step 1, an S3 bucket is created in the Log archive account.  If you already have an S3 bucket in a central location that you could reuse for conformance packs, you may select No.
  • If you created S3 bucket by selecting SetupConformancePack: Yes. Write down the S3 bucket name from the output section of the AWS CloudFormation stack.
  • Log in to the Log archive account.
  • Look for an AWS CloudFormation Stack name that starts with StackSet-CNFPACK-LOGARCHIVE-CUSTOM-CONFIG-STACKSET
  • Choose output section and note down the S3 bucket name.
  • If you selected SetupConformancePack: No while deploying stack in step 1, identify and write down the S3 bucket that you want to use while deploying the conformance pack.
  • Deploy the conformance pack across all Regions you subscribed to (us-west-1 and ap-northeast-1 in this example) and in which you enabled the AWS Config recorder. Replace the awsconfigconforms-your-bucket and your-region values that are applicable to your environment.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name="CT-Conformance-Pack" --template-body="file://CTConformancePack.yaml" --delivery-s3-bucket="{awsconfigconforms-your-bucket}" --region &lt;your-region&gt;

To list AWS accounts to be excluded from an organization conformance pack while deploying a conformance pack, use the –excluded-accounts option.

  • Run the following command to check the status of the conformance pack across multiple accounts. It may take up to five minutes to reflect the status in the command output.
aws configservice get-organization-conformance-pack-detailed-status --organization-conformance-pack-name CT-Conformance-Pack --region &lt;your-region&gt;
  • To deploy conformance pack on other Regions, repeat the above put-organization-conformance-pack/get-organization-conformance pack commands on the remaining Regions.
  • On completion of the section, you will be able to see any non-compliant resources on these Regions in the AWS Config Aggregator console in the Audit account. You can access the console using below link in your Audit account:

http://console.thinkwithwp.com/config#/aggregate-dashboard/aws-controltower-GuardrailsComplianceAggregator/<ct-home-region>/. 

Note that the non-compliance resources from these additional Regions you added by following this post will not be reported on the AWS Control Tower Dashboard.

Step 4: Upgrade steps when a new Region support is added to AWS Control Tower

In the event that AWS Control Tower adds support to new Region, for example us-west-1, here’s what you must do. Perform the following actions before you start upgrading your AWS Control Tower to enable the new Region:

  • Log in to your main account.
  • Look for the StackSet with name NewStackSetName you provided in step 1.
  • Under stack instances, identify the list of accounts that has deployments in the new AWS Region. Here, we use us-west-1.
  • Follow the steps to delete the stack instances from us-west-1.
  • Delete the newly supported Region from the Parameter store (https://console.thinkwithwp.com/systems-manager/parameters/CFN-RegionsToDeployParam-xxxxxxxxxxx) to avoid creation of stacks on the new Region for accounts you create in the future.
  • To avoid additional charges, delete the conformance pack on the new Region. Replace us-west-1 with the new Region as needed and run the following command.
aws configservice delete-organization-conformance-pack --organization-conformance-pack-name "CT-Conformance-Pack" --region us-west-1
  • Update the Landing Zone. The new Region stacks will get added to the AWSControlTowerBP-BASELINE-CONFIG StackSet.
  • Optionally, for testing, delete few Stack instances from NewStackSetName and add them back. You should be able to see AWS Config disabled when Stack instances are deleted and enabled back without an issue once created back.

Step 5 : Optionally deploy additional guardrails using Config Conformance Packs

As in the previous step, you can further extend your governance by deploying additional Conformance Packs, such as Operational Best Practices for NIST CSF or any of the other available ones. We will continue to use the method from step 3, enabling the conformance pack at the organization level.

All that is required is to download the relevant pack you wish to deploy and run the following command, updating the path to where you saved the template:

aws configservice put-organization-conformance-pack --organization-conformance-pack-name="NIST-CSF-Conformance-Pack" --template-body="file://NISTCSFConformancePack.yaml" --delivery-s3-bucket="{awsconfigconforms-your-bucket}" --region &lt;your-region&gt;

To make sure you understand the options, be sure to read carefully the points highlighted on the previous steps .

To check for the status of the newly deployed pack, run the following command. It may take up to five minutes to reflect the status in command output.

aws configservice get-organization-conformance-pack-detailed-status --organization-conformance-pack-name NIST-CSF-Conformance-Pack --region &lt;your-region&gt;

Repeat the above process on any remaining Regions or for any additional packs you want to apply to your environment.

As previously, you will be able to see any non-compliant resources on these Regions in the AWS Config Aggregator console in the Audit account. You can access the console using the following link in your Audit account: http://console.thinkwithwp.com/config#/aggregate-dashboard/aws-controltower-GuardrailsComplianceAggregator/<ct-home-region>/.

Cleanup

If you are experimenting and want to clean this up after testing or decide not to go with this approach, follow the steps below to clean up the solution that you set up in this walkthrough:

  • Delete the stack instances from the StackSet NewStackSetName that you created in Step 1.
  • After removing all stack instances, delete the StackSet.
  • If you have selected SetupConformancePack: Yes, you must delete the stack instances and StackSet CNFPACK-LOGARCHIVE-CUSTOM-CONFIG-STACKSET. The S3 bucket is created in the LogArchive account. This bucket is not deleted when you delete the StackSet. Delete it manually if needed.
  • Run the following command  on you main account to delete the conformance pack that you deployed at organization level in Step 3:
aws configservice delete-organization-conformance-pack --organization-conformance-pack-name "CT-Conformance-Pack" --region us-west-2
  • Change the Region name. If needed, to delete organization conformance pack on multiple Regions, repeat the previous command.
  • To deregister the delegated admin, run this command from the main account:
aws organizations deregister-delegated-administrator --account-id="{Audit-Account-ID}" --service-principal=config-multiaccountsetup.amazonaws.com

Conclusion

In this post, we showed you how to enable AWS Config, add the accounts to AWS Config Aggregator and enable detective guardrails in the Regions where AWS Control Tower is yet to be available. We used existing AWS Control Tower resources to provide a path forward to revert to AWS Control Tower with minimal efforts as and when the new Region is supported.

With this, you can start deploying AWS Control Tower in one of the supported Regions and independently enable the baselines and guardrails on the remaining AWS Regions. You can take advantage of the well-architected landing zone and best-practices blueprints. You can also enable governance by using guardrails that come with AWS Control Tower apply additional governance policies using AWS Config conformance packs.

About the authors

Kishore Vinjam is a partner solutions architect focusing on AWS Control Tower, AWS Service Catalog, and AWS Marketplace. He is passionate about working in cloud technologies, and working with customers and building solutions for them. When not working, he likes to spend time with his family, hike, and play volleyball and ping-pong.

 

 

 

Raphael is a technical business development manager for Service Catalog & Control Tower. He enjoys tinkering with automation and code and active member of the management tools community.