AWS Cloud Operations Blog

AWS Config RDK: Multi-account and multi-Region deployment

We have introduced an updated version of the AWS Config Rule Development Kit (RDK). The RDK helps you rapidly deploy custom AWS Config rules at scale across multiple AWS accounts and Regions. You can also create a centralized dashboard to view the AWS Config rule compliance status across various AWS accounts.

This blog post is a continuation of our previous post – How to develop custom AWS Config rules using the Rule Development Kit. In the previous blog post, my colleague demonstrated how to prototype, develop, and deploy custom AWS Config rules at scale within a single AWS account. The steps for prototyping and developing the custom AWS Config rules for multi-account deployments remain the same. The variation is in the deployment step, which I’ll walk you through in this blog post. I encourage you to review the previous blog post, so that you can follow along here.

Solution overview

Here is a quick overview of the solution and the various components involved.The solution assumes that AWS Config is enabled on all AWS accounts that are part of the solution. To enable AWS Config across multiple account use an AWS CloudFormation stack set.

This solution creates AWS Lambda functions in a master account, which is designated here as the “Compliance account.” These functions serve as the central compliance evaluation engine for the same custom AWS Config rule deployed to multiple AWS accounts spread across multiple Regions, designated as the “Satellite accounts”. A new RDK feature grants permissions for the custom AWS Config rules in satellite accounts to invoke corresponding Lambda functions in the compliance account.

The following diagram shows the architecture of the multi-account and multi-Region AWS Config RDK deployment along with the various components:

Here is how it works:

  • The compliance account is the central account where the security team managing the AWS Config rules deploys their AWS Config evaluation Lambda functions. This is usually the central security account or some account providing similar functionality. This enables the security team to manage all AWS Config rule logic in one place. This has the additional benefit of ensuring that the rule logic cannot be modified by individual teams managing the different AWS accounts hosting the resources to be evaluated.
  • The compliance account also has the necessary permissions, via a cross-account execution role that runs the AWS Config rule evaluation in the remote accounts.
  • The satellite accounts are those accounts where the AWS Config evaluation takes place against applicable AWS resources. These are generally the application or shared services accounts primarily managed by other teams in the organization, but the security/compliance team enforces the organization standard.
  • As AWS Config rules get evaluated in the satellite accounts, the AWS Config data is stored in an Amazon S3 bucket for AWS Config data that the individual satellite accounts have defined.
  • The decentralized AWS Config data is aggregated back in the central compliance account through AWS Config aggregators. This provides a single-pane view of the AWS resource compliance status against the organization-defined security posture.

The multi-account and multi-Region architecture is based on the following advanced RDK deployment features:

  • Function-only deployment – With this flag (-f) on the deploy command, RDK will deploy only the Lambda functions, Lambda execution role, and Lambda permissions to the central compliance account that hosts the AWS Config evaluation logic.
  • Create-rule-template command – This command generates a CloudFormation template that defines the AWS Config rules themselves. The template also deploys the AWS Config role, AWS Config data bucket, configuration recorder, and delivery channel necessary for the AWS Config rules to work in multiple AWS accounts where the AWS Config rules need to be evaluated against AWS resources. If you have an existing AWS Config environment set up and you only want to deploy the AWS Config rules, use the ‘—rules-only’ flag.

Cross-account deployment walkthrough

After you have defined an AWS Config rule and prototyped using the AWS Config RDK as described in a previous blog post, use the following steps to deploy the various AWS Config components across the compliance and satellite accounts.

Prerequisite

Set up the AWS CLI with credentials for the compliance account. The next steps are performed in the compliance account only.

Update the AWS Config rule

Edit the AWS Config rule developed by the RDK to enable it to assume the role in other AWS accounts. Set the “ASSUME_ROLE_MODE = True”. This is required for multi-account deployment where the Lamda functions in the compliance account are designed to run evaluations in the remote satellite accounts.

Deploy the AWS Config Lambda function

Use the RDK deploy command “-f or -functions-only” flag for deploying only the Lambda function in the compliance account. This deploys the AWS Config Lambda functions, Lambda execution role, and Lambda permissions in the compliance account, but it does not deploy the actual AWS Config rules. All these are deployed through a CloudFormation stack.

The following screenshot from the CloudFormation console shows the CloudFormation stack deploying the necessary AWS Config rule components:

This screenshot from the Lambda console shows the deployed Lambda function.

This screenshot from the IAM console shows the provisioning of the IAM role required by the Lambda function.

The following screenshot shows the creation of the permission policy required by the AWS Lambda role.

Prepare for cross-account deployment

Generate the CloudFormation template necessary to deploy the rest of the AWS Config rule components in the remote satellite accounts. The components include the AWS Config rules, the AWS Config role, the AWS Config data bucket, the configuration recorder, and the delivery channel necessary for the AWS Config rules to work in a satellite account.

This is done by using the “create-rule-template” argument from the RDK.

Using the “—all” flag you can aggregate all your RDK-generated AWS Config rules into a single CloudFormation template for deployment into satellite accounts. If you’d rather, you can specify your rule name (in my case it is “MyRule”), so that the generated CloudFormation template only includes the specific AWS Config rule.

This would result in a CloudFormation template that would look like this:

Deploy into satellite accounts

Deploy the generated CloudFormation template into the desired remote satellite accounts. In this walkthrough I’ll deploy the template manually through the AWS Management Console, but you can use any of the available options to deploy the template including the CLI, as an AWS CodePipeline task, using StackSets, or using your existing CI/CD pipelines.

Note: This step is to be performed in the satellite account and not in the central compliance account.

In the CloudFormation console, select the CloudFormation template.

Provide a name for the stack. Provide the necessary parameters. My AWS Config rule evaluates the existing EC2 instance types in the satellite account against a desired instance type. This template takes in the desired EC2 instance type as the parameter.

Provide the AWS account ID of the Compliance account where the AWS Config Lambda evaluators reside in the “LambdaAccountId”.

Complete the rest of the CloudFormation deployment options your organization’s standard requires, and deploy the stack. After it is complete the stack creates the AWS Config rule, the AWS Config data bucket, the recorder, the IAM role, and the delivery channel.

Now you should see the corresponding AWS Config rule in your satellite accounts.

You can also see the compliance status against those rules.

Create a central dashboard

Now you might want to view the compliance status of the AWS Config rules in the multiple satellite accounts in your central compliance account. You can do this by creating an Aggregated View in your compliance account.

Go to AWS Config in your compliance account and add an aggregator.

Now enable the replication of data from other satellite accounts. You can either add individual AWS accounts or choose to add all AWS accounts under your organization in AWS Organizations.

It takes time for the central aggregated view to populate. When this view is populated, you can see the status of all your deployed AWS Config rules from all satellite accounts from your compliance account.

Further enhancement

There are multiple ways the RDK and its multi-account and multi-Region deployment capability can be used to build more complex and automated solutions. One such use case has been demonstrated in the Engine for Compliance-as-Code solution.

The objective of the solution is to accomplish the following:

  1. Deploy automatically and operate configurable sets of AWS Config rules in a multi-account and multi-Region environment.
  2. Provide insights and records on the compliance status of all AWS accounts and resources.
  3. Provide an initial set of recommended AWS Config rules.

This solution uses the multi-account and multi-Region deployment feature of the RDK to automate the deployment of AWS Config rules across multiple AWS accounts and Regions. This solution enables you to design a one-step process for creating new AWS accounts spread over multiple Regions and deploy necessary AWS Config rules as they are provisioned.

Conclusion

AWS Config is a powerful tool to maintain and enforce compliance of AWS resources. Using the solution described in this blog post, you can use the AWS Config RDK to generate and deploy AWS Config rules across multiple AWS accounts and Regions from a central AWS account. This gives your AWS Config rules the scalability required for an enterprise scale deployment. The Lambda functions used for evaluation of the AWS Config rules are deployed in the central Compliance account, which eases the management of AWS Config rules at scale. This also ensures that the evaluation logic can’t be tampered with by enforcing strict access control to the compliance account. The AWS Config rules are deployed in the satellite accounts, which helps the solution to scale as new accounts and Regions are added. Using the AWS Config aggregator view, the compliance status across the satellite accounts is reported back in the central compliance account. This provides a single pane glass view of the organization’s AWS infrastructure security posture.

This builds a comprehensive “Compliance as Code” solution for an enterprise using all cloud native component based on the security tenet of using the cloud to protect the cloud.

For further details on the solution, refer to the aws-config-rdk on AWS labs. if you require a special enterprise enhancement, contact AWS professional services.

Acknowledgements

I would like to thank my colleagues Michael Borchert and Jonathan Rault for building and maintaining the RDK.

About the Author

Avik Mukherjee is a Security Architect with more than a decade of experience in IT Governance, Security, Risk and Compliance. He is part of the AWS professional services teams that work with clients to assist them in their journey to transform the security posture of their resources running on AWS. He loves spending time with his family and working on his culinary skills.