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.
