Skip to content
Contino
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Events
  • Blog
  • Join Us
  • Contact Us
Gerald Bachlmayr

How to Use AWS Config Aggregator to Get a Single View of Compliance Across Your Entire Enterprise Landscape

Every organisation wants to improve the digital customer experience and speed up their release cycles to be ahead of the game. This means our environments and application footprints are continuously changing.

Continuous change also means that there is a risk of misconfiguration, which can lead to malfunctions or security issues. In large organisations there are typically inconsistent maturity levels between teams. Therefore every organisation needs a safety net that prevents it from being exposed to data leaks and other vulnerabilities.

AWS Config enables compliance automation, allowing you to manage continuous change while staying in line with compliance and governance requirements. 

It is a fully-managed service that enhances security and governance by providing you with an AWS resource inventory, configuration history, and configuration change notifications. Config Rules enables you to create rules that automatically check the configuration of AWS resources as recorded by AWS Config. With this service you can discover existing and deleted AWS resources, determine your overall compliance against rules, and dive into the configuration details of a resource at any point in time. These capabilities enable compliance auditing, security analysis, resource change tracking, and troubleshooting.

By leveraging the ‘Aggregator’ feature of AWS Config, the approach can be uplifted to an enterprise scale across accounts and regions.

In this blog, I’ll take you through the steps required to use AWS Config Aggregator to get a single-pane view of governance and compliance across the enterprise landscape.

How Can We Automate It?

AWS Config continuously monitors and records our configurations and allows us to automate the evaluation against desired configurations.

By utilising the Aggregator feature we can collect configuration and compliance data from multiple accounts and regions for the following use cases:

  • Multiple accounts and multiple regions
  • Single account and multiple regions
  • All accounts within an AWS Organizations

AWS Aggregator provides a combined view in your aggregator account in your region of choice.

The aggregator account can be the master account as part of AWS Organizations or a different account. Using the master account is easier because you are automatically authorised to aggregate logs from all the accounts that are part of your AWS Organization. We will proceed with this setup in our example.

The simplest way to action rule violations are through managed remediation actions. Here are some examples:

  • S3: Disable public read and write for an S3 bucket
  • EC2: Create snapshot, restart an instance, execute EC2 Rescue
  • RDS: create a snapshot, reboot, start and stop instance

The managed remediation actions are SSM Automation Documents and we will use one later on in this example. 

Step-By-Step Instructions

These are the detailed steps that are required to get an aggregated view for all accounts and regions within an AWS Organization:

Create a S3 Bucket for Centralised Logging

We create a new S3 bucket in the aggregator account. This bucket will later be used by all source accounts to store the Config log files. Because we are going to use Conformance Packs later on, the name of the delivery S3 bucket must start with “awsconfigconforms”.

Enable Config Recorder And Define a Delivery Channel

Now we need to deploy the Recorder and Delivery Channel as a StackSet to our Organization.
We create a StackSet by deploying our CloudFormation template with the following command:

aws cloudformation create-stack-set --stack-set-name config-recorder-org --template-body file://enableConfig-in-org.yml --capabilities CAPABILITY_NAMED_IAM --permission-model SERVICE_MANAGED --auto-deployment Enabled=true,RetainStacksOnAccountRemoval=false

After the StackSet is created we need to create our AWS resources within all accounts and specified regions in our Organization with the following command:

aws cloudformation create-stack-instances --stack-set-name config-recorder-org --deployment-targets OrganizationalUnitIds="ou-enen-r6ziod3r" --regions "us-east-1" "us-east-2" "ap-southeast-2" "us-west-1" "us-west-2"

There can only be one Recorder and one Delivery Channel in each account. If there are issues the following commands will help to find out more:

  • aws configservice describe-configuration-recorders: This will give us the Recorder name if it already exists in our account and we can delete it with: aws configservice delete-configuration-recorder --configuration-recorder-name default
  • aws configservice describe-delivery-channels: If we receive the name of a delivery channel as a response we can delete it with: aws configservice delete-delivery-channel --delivery-channel-name default

Replace the word “default” if the recorder or delivery channel has a different name.

Setup of an Aggregator

Before setting up the Aggregator we need to make sure that all features in our Organization are enabled. We define the Aggregator and the IAM role in a CloudFormation template:

Resources: ConfigAggregator: Type: AWS::Config::ConfigurationAggregator Properties: ConfigurationAggregatorName: !Ref AggregatorName OrganizationAggregationSource: AllAwsRegions: true RoleArn: !GetAtt OrgRecorderRole.Arn OrgRecorderRole: Type: AWS::IAM::Role Properties: AssumeRolePolicyDocument: Version: 2012-10-17 Statement: - Effect: Allow Principal: Service: - config.amazonaws.com Action: - 'sts:AssumeRole' Path: / Description: Role for the AWS Config Recorder ManagedPolicyArns: - arn:aws:iam::aws:policy/service-role/AWSConfigRoleForOrganizations RoleName: OrgRecorderRole

Please note, there is a separate IAM service role for Config deployments to our Organization called AWSConfigRoleForOrganizations. Since we only need one Aggregator we deploy the template as a CloudFormation Stack - not as a StackSet. Optionally we can send SNS notifications to a topic. If we do that then the SNS topic must have policies that grant access permissions to AWS Config.

Defining the S3 Bucket Policy

As a first step we created a S3 bucket in the aggregator account that can be used by the source accounts. We now need to setup the S3 bucket policy to make sure the source accounts can write to the bucket:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AWSConfigBucketPermissionsCheck", "Effect": "Allow", "Principal": { "Service": "config.amazonaws.com" }, "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::awsconfigconforms-bachlmayr" }, { "Sid": "AWSConfigBucketDelivery", "Effect": "Allow", "Principal": { "Service": "config.amazonaws.com" }, "Action": "s3:PutObject", "Resource": "arn:aws:s3:::awsconfigconforms-bachlmayr/*" }, { "Sid": "AllowGetObject", "Effect": "Allow", "Principal": "*", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::awsconfigconforms-bachlmayr/*", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "707549494633" }, "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/aws-service-role/config-conforms.amazonaws.com/AWSServiceRoleForConfigConforms" } } }, { "Sid": "AllowGetBucketAcl", "Effect": "Allow", "Principal": "*", "Action": "s3:GetBucketAcl", "Resource": "arn:aws:s3:::awsconfigconforms-bachlmayr", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "707549494633" }, "ArnLike": { "aws:PrincipalArn": "arn:aws:iam::*:role/aws-service-role/config-conforms.amazonaws.com/AWSServiceRoleForConfigConforms" } } } ] }

Once we have setup the Aggregator and the bucket policy we can see which accounts are being monitored:

Deployment of Conformance Pack & Auto-Remediation

Recently, AWS released a new Config feature called Conformance Packs. They allow us to bundle Config Rules and deploy them across our Organization. Let’s have a look how this works: We can either write our own Conformance Packs in YAML format or we can use any of the pre-canned sample templates, for example:

  • Control Tower Detective Guardrails
  • Best Practices for PCI-DSS
  • Best Practices for DynamoDB
  • Best Practices for S3

In this example we will use the one for the S3 best practices.

But before the deployment we will modify and add a remediation to it to automatically remediate any public access to S3 buckets:

S3PublicWriteRemediation: DependsOn: S3BucketPublicWriteProhibited Type: 'AWS::Config::RemediationConfiguration' Properties: ConfigRuleName: S3BucketPublicWriteProhibited ResourceType: "AWS::S3::Bucket" TargetId: "AWS-DisableS3BucketPublicReadWrite" TargetType: "SSM_DOCUMENT" TargetVersion: "1" Parameters: AutomationAssumeRole: StaticValue: Values: - arn:aws:iam::707549494633:role/S3RemediationRole S3BucketName: ResourceValue: Value: "RESOURCE_ID" ExecutionControls: SsmControls: ConcurrentExecutionRatePercentage: 10 ErrorPercentage: 10 Automatic: True MaximumAutomaticAttempts: 10 RetryAttemptSeconds: 600

Once we have done that we need to create the referenced S3RemediationRole role with the required permission. We are doing that by deploying the following CloudFormation template:

Resources: S3RemediationRole: Type: "AWS::IAM::Role" Properties: RoleName: S3RemediationRole AssumeRolePolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Principal: Service: - "ssm.amazonaws.com" Action: - "sts:AssumeRole" Path: "/" S3OperationsAutomationExecutionRolePolicies: Type: "AWS::IAM::Policy" Properties: PolicyName: "S3RemediationRolePolicy" PolicyDocument: Version: "2012-10-17" Statement: - Effect: "Allow" Action: - "s3:PutBucketPublicAccessBlock" Resource: "*" Roles: - Ref: "S3RemediationRole"

Once the IAM role is create we deploy the S3 best practices conformance pack including our added remediation with the following command:

aws configservice put-organization-conformance-pack --organization-conformance-pack-name="S3ConformancePackOrg" --template-body="file://conformance-pack-s3-org.yml" --delivery-s3-bucket=awsconfigconforms-bachlmayr

Once the conformance pack is deployed we can see the included rules under “Conformance Packs” in the Config console:

You can also see a list of conformance packs using the following CLI command:

aws configservice describe-organization-conformance-packs

Aggregated View

Now that all the rules are up and running we can get a consolidated view in the Aggregator. We can see an aggregated inventory and consolidated view of our compliance status and the top non-compliant rules:

The “Rules” view within the Aggregator gives us a per-rule view and helps us to identify resources that do not comply with the rule. We can filter the view by compliant/non-compliant, region and Account ID.

Summary

AWS Config Aggregator helps us to get a single-pane view of governance and compliance across the enterprise landscape. By using Conformance Packs we can manage groups of rules. Sending the rule evaluation outcomes from all source accounts to a central S3 bucket enables us to get consolidated log files. AWS Config is a really powerful service that helps us to govern the entire enterprise AWS landscape.

More Articles

How to Use Systems Thinking to Find and Fix the *Root Cause* of Your Organisational Woes

15th May 2020 by Simon Copsey

Best Practices for MLOps and the Machine Learning Lifecycle

12th May 2020 by Katinka Gereb

How to Hold Successful Value Stream Maps Remotely

7th May 2020 by Carlos Nunez

Sign-up: Insights Directly to Your Inbox

Join tens of thousands of your peers and sign-up for our best content and industry commentary, curated by our experts.

You may unsubscribe from these communications at any time. For more information on how to unsubscribe, our privacy practices, and how we are committed to protecting and respecting your privacy, please review Privacy Policy.
Contino
  • Londonlondon@contino.io
  • New York newyork@contino.io
  • Atlantaatlanta@contino.io
  • Melbournemelbourne@contino.io
  • Sydneysydney@contino.io