Governance & Compliance Automation With AWS Config
Why Do You Need Governance and Compliance Rules?
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.
Therefore we want the configuration of our AWS resources continuously assessed, audited and evaluated. This is exactly what AWS Config does and once an unexpected configuration change is detected it can automatically be remediated if required.
How Does it Work?
AWS Config continuously monitors and records our configurations and allows us to automate the evaluation against desired configurations. For example you can automatically validate if all your S3 buckets are private with two managed rules called “s3-bucket-public-write-prohibited” and “s3-bucket-public-read-prohibited”. Another example is the “approved-amis-by-id” rule to assess if only approved AMIs (Amazon Machine Image) are being used. The Config dashboard shows you a resource inventory and provides an overview of which rules are compliant and noncompliant:
If an unexpected configuration change is detected you have different options how you can action them:
Built-in remediations:
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
- DynamoDB: create backup, delete backup
The managed remediation actions are SSM Automation Documents. A complete list can be found here: https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-documents-reference-details.html
SNS notifications
Once a rule violation or change from a previous state is discovered a SNS notification can be sent to a SNS topic. Any resources that are subscribed to the SNS topic can then action the rule violation. E.g. a Lambda function could set the S3 bucket to private or send a notification to Slack.
CloudWatch
You can also intercept the event with a CloudWatch rule like the one listed below.
You can set a CloudWatch Target to trigger any action. This could be a SSM Run Command, a Step Function, or any other target that is supported by CloudWatch.
Step By Step Instructions
In this example we want to make sure that only approved AMIs can be launched as an EC2 instance. Any other instances will be stopped automatically.
Enable Config Recorder And Define a Delivery Channel
To get started with Config you need to enable the Recorder. You can do that either with CloudFormation, CLI or the AWS Console. The default retention time for AWS Config data is 7 years but you can change that. Config will need permission to run and you can either use the default AWSServiceRoleForConfig in your account or create a new role. The delivery method can be a new or an existing bucket in your account or in a different account. You can also send all log streams to a SNS topic, but S3 will be the preferred method for most use cases.
Below is a CloudFormation template for a Recorder and a Delivery Channel:
In the DeliveryChannel section you define to which bucket the log files will be delivered to and also the delivery frequency for the log files.
Define a Config Rule
For this example we are using the managed config rule APPROVED_AMIS_BY_ID. Using this rule we want to make sure that only a particular AMI is being used. The AMI is defined in the Parameters Section of the template.
In the Scope section you can limit the scope to one or more resource types and if you don’t define the scope all resources types will be recorded. The InputParameters field is optional, but since we are defining a RemediationConfiguration later on we have to define it now. Config is passing this value to the AWS Config rule Lambda function and the string needs to be in JSON format. Under Source we define the rule owner which can be AWS for managed rules, or otherwise CUSTOM_LAMBDA. With SourceIdentifier we define the managed rule that is being used.
In the Resource section we can reference the parameter from above:
Define a Remediation
As a next step we want to configure a remediation by creating a RemediationConfiguration resource. We enable automatic execution with the true flag and reference the rule we want to remediate under ConfigRuleName. Now let’s look at the items under the Parameters field. We need to define an IAM role to perform the remediation and in this example we are using the AWSServiceRoleForConfig service role that is already in your account. By using the AWS::AccountId Pseudo Parameter we don’t need to hard code our AWS account number in the template.
Under InstanceId we reference the output value for instanceId, which then shows us which instance Id was remediated due to a rule violation.
ResourceType is optional and we limit the scope to EC2 resources.
Under TargetId we reference any of the SSM Automation Documents that we want to trigger. Once we deploy our CloudFormation templates we have a fully functioning Config dashboard with one operating rule including an auto-remediation.
Summary
AWS Config helps you to define a variety of governance rules that are continuously being monitored and can also trigger remediations or notifications if the actual configuration status differs from the expected status. In our example we defined a recorder and delivery channel, define a rule and define a remediation.
AWS Config also offers an Aggregator feature providing an aggregated view across several accounts and regions.This enables a scalable and automated enterprise governance approach. Have a look at “Enterprise Governance with AWS Aggregator and Conformance Packs” of this two part blog series to find out more.
