AWS Cloud Operations & Migrations Blog

Remediate noncompliant AWS Config rules with AWS Systems Manager Automation runbooks

AWS Config is used to assess, audit, and evaluate the configuration of your AWS resources. You can use a set of AWS Config managed rules for common compliance scenarios or you can create your own rules for custom scenarios.

In this blog post, I explain how AWS Systems Manager Explorer gathers the compliance status of AWS Config rules in your AWS accounts across AWS Regions and how to use Systems Manager Automation documents (runbooks) to resolve your noncompliant AWS Config rules.

AWS Systems Manager Automation simplifies common maintenance and deployment tasks for Amazon Elastic Compute Cloud (Amazon EC2) instances and other AWS resources. Automation enables you build automations to configure and manage instances and AWS resources. You can create custom runbooks or use predefined runbooks maintained by AWS.

AWS Systems Manager Explorer is a customizable operations dashboard that reports information about your AWS resources. Explorer displays an aggregated view of operations data (OpsData) for your AWS accounts and across AWS Regions. Explorer provides context into how operational issues are distributed, trend over time, and vary by category.

The following diagram shows the architecture of the solution.

Diagram shows the interaction between AWS Config, Explorer, and Automation workflows to remediate rules automatically or manually.

Figure 1: AWS Config rules remediation with automation runbooks architecture

Solution overview

In this post, I’ll show you how to complete the following steps:

  • Set up an AWS Identity and Access Management (IAM) role for Automation to access Systems Manager Automation workflows to remediate your noncompliant AWS Config rules.
  • Configure Automation runbooks to remediate and resolve noncompliant AWS Config rules.

Prerequisites

Use the information in the Aggregate operational tasks with AWS Systems Manager Explorer and OpsCenter blog post to complete these steps:

  • Use AWS Systems Manager Quick Setup to set up Explorer.
  • Create AWS Config rules. Explorer gathers the compliance status of AWS Config rules and resources in your AWS account.

After you complete these steps, a rules compliance summary is displayed in the AWS Config dashboard, as shown in Figure 2. The Explorer dashboard will be updated in a few hours.

Rules page displays a table with columns for the rule name, remediation action (in this example, Not set), type (AWS managed), and compliance (Noncompliant resource).

Figure 2: AWS Config rules compliance summary

Set up Automation

AWS provides a library of Automation documents that you can choose for a variety of operational tasks. You can build, run, and share automations with others on your team or inside your organization.

Figure 3 shows the Automation document categories for the automation of your operational tasks.

Choose document page displays tabs for Owned by Amazon (in this example, selected), Owned by me, Shared with me, and All documents. The document categories include Remediation, Patching, Security, Instance management, Data backup, and more.

Figure 3: Automation documents

If your IAM user account, group, or role is assigned administrator permissions, then you have access to Systems Manager Automation. If you don’t have administrator permissions, then an administrator must give you permission by assigning the AmazonSSMFullAccess managed policy, or a policy that provides comparable permissions, to your IAM account, group, or role. The IAM policy AmazonSSMFullAccess grants permissions to Systems Manager actions. However, some runbooks require permissions to other services, such as the runbook AWS-ReleaseElasticIP, which requires IAM permissions for ec2:ReleaseAddress. Review the actions taken in a runbook to ensure your IAM user account, group, or role is assigned the permissions required to perform the actions included in the runbook.

Automations can be initiated under the context of a service role (or assume role). This allows the service to perform actions on your behalf. If you do not specify an assume role, Automation uses the context of the user who invoked the automation. For information about creating a service role, see Use AWS CloudFormation to configure a service role for Automation or Use IAM to configure roles for Automation in the AWS Systems Manager User Guide.

In this post, I use an AWS CloudFormation template to create the Automation service role.

  1. Download the AWS-SystemsManager-AutomationServiceRole.zip This folder includes the AWS-SystemsManager-AutomationServiceRole.yaml CloudFormation template file.
  2. Sign in to the AWS CloudFormation  console and choose Create Stack.
  3. In Specify template, choose Upload a template file.
  4. Choose the AWS-SystemsManager-AutomationServiceRole.yaml file and then choose Next.

Under Specify template, the Upload a template file option is selected. Under Upload a template file, the AWS-SystemsManager-AutomationServiceRole.yaml file is displayed.

Figure 4: Creating Automation service role

  1. For the stack name, enter automation-role.
  2. Under Configure stack options, leave the defaults, and then choose Next.
  3. On the Review page, select the I acknowledge that AWS CloudFormation might create IAM resources with custom names checkbox to create the CloudFormation stack.

The Resources tab of the automation-role page is selected. It displays a logical ID (in this example, AutomationServiceRole), physical ID (AutomationServiceRole), type (AWS::IAM::Role), and status (CREATE_COMPLETE).

Figure 5: Automation service role

  1. To get the ARN for the Automation service role, choose the AutomationServiceRole Your ARN will be similar to arn:aws:iam::[AWS Account ID]:role/AutomationServiceRole.
  2. Some runbooks require permissions to other services. I add EC2, S3, and DynamoDB full access inline IAM policies to the Automation service role, as shown in Figure 6. If an administrator performs operational tasks automation, you can keep these full access IAM policies, but always check the Automation documents and provide only required policies to the Automation service role.

The Summary page for AutomationServiceRole includes tabs for Permissions, Trust relationships, Tags, Access Advisor, and Revoke sessions. The Permissions tab is selected and there are five AWS managed policies in the list.

Figure 6: Automation service role inline IAM policies

You can now use the Automation service role ARN in your runbooks. For information about creating your own Automation runbooks, see the New Automation Features in AWS Systems Manager blog post.

Depending on your use case, you can run automations by using different security models or target and rate controls. You can run automation with approvers or you can run a manual automation.

In this post, you will remediate and resolve noncompliant AWS Config rules by using Automation runbooks.

Remediate your noncompliant AWS Config rules

AWS Config shows how AWS resources in your AWS account are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time.

You can use a set of AWS Config managed rules for common compliance scenarios or you can create your own rules for custom scenarios. When an AWS resource is found to be noncompliant, you can specify a remediation action through an AWS Systems Manager Automation document.

As part of the prerequisites, you have already created five AWS Config rules. I’ll show you how to remediate these noncompliant rules automatically by using Automation runbooks. You can also use the manual remediation option. The process I describe here works if you are using just one AWS account. It’s a little different if you have multiple accounts.

  1. From the left navigation pane of the AWS Systems Manager console, choose Explorer.

Explorer dashboard displays OpsItems by status (in this example, 3 unresolved and 3 open) and an AWS Config compliance summary (0 compliant and 5 noncompliant rules).

Figure 7: Noncompliant rules in Explorer dashboard

  1. On the Explorer page, in AWS Config Compliance Summary, choose 5 to initiate the remediation of the noncompliant rules.

Under OpsData, the dynamodb-ptr-enabled, eip-attached, rds-instance-deletion-protection-enabled, s3-bucket-server-side-encryption-enabled, and s3-bucket-versioning-enabled rules are displayed. All have a Remediation action of Not set and all have noncompliant resources.

Figure 8: Noncompliant rules with no remediation action

  1. Choose the s3-bucket-server-side-encryption-enabled On the details page for the rule, from Actions, choose Manage remediation, as shown in Figure 9.

Details page for s3-bucket-versioning-enabled includes sections for rule details (description, ARN, trigger type, last successful evaluation, and more) and parameters.

Figure 9: Details page for s3-bucket-versioning-enabled

  1. On Edit: Remediation action, enter the following values, and then choose Save changes.
    • Under Select remediation, choose Automatic remediation. Leave the defaults for Retries in (5) and Seconds (60).
    • For Choose remediation action, select AWS-ConfigureS3BucketVersioning.
    • Under Rate limits, for Concurrent Execution Rate, enter 25. For Error Rate, enter 35.
    • Under Resource ID parameter, choose BucketName so that the runbook will automatically remediate all noncompliant S3 buckets.
    • Under Parameters, for AutomationAssumeRole, enter the ARN of your Automation service role.

Edit: Remediation action displays fields completed as described in the procedure.

Figure 10: s3-bucket-versioning-enabled

  1. To remediate the s3-bucket-server-side-encryption config rule:
    • Under Select remediation, choose Automatic remediation. Leave the defaults for Retries in (5) and Seconds (60).
    • For Choose remediation action, select AWS-EnableS3BucketEncryption.
    • Under Rate limits, for Concurrent Execution Rate, enter 25. For Error Rate, enter 35.
    • Under Resource ID parameter, choose BucketName so that the runbook will automatically remediate all noncompliant S3 buckets.
    • Under Parameters, for AutomationAssumeRole, enter the ARN of your Automation service role.

Edit: Remediation action displays fields completed as described in the procedure.

Figure 11: s3-bucket-server-side-encryption

  1. To remediate the rds-instance-deletion-protection-enabled config rule:
    • Under Select remediation, choose Automatic remediation. Leave the defaults for Retries in (5) and Seconds (60).
    • For Choose remediation action, select AWS-ConfigRemediation-EnableRDSInstanceDeletionProtection.
    • Under Rate limits, for Concurrent Execution Rate, enter 25. For Error Rate, enter 35.
    • Under Resource ID parameter, choose DbInstanceResourceID so that the runbook will remediate all noncompliant RDS instances automatically.
    • Under Parameters, for ApplyImmediately, enter true. For AutomationAssumeRole, enter the ARN of your Automation service role.

Remediation action details is expanded to display AWSConfigRemediation-EnableRDSInstanceDeletionProtection and details about the document. The Rate Limits, resource ID parameter, and Parameters sections are completed as described in the procedure.

Figure 12: rds-instance-deletion-protection-enabled

  1. To remediate the eip-attached config rule:
    • Under Select remediation, choose Automatic remediation. Leave the defaults for Retries in (5) and Seconds (60).
    • For Choose remediation action, select AWS-ReleaseElasticIP.
    • Under Rate limits, for Concurrent Execution Rate, enter 25. For Error Rate, enter 35.
    • Under Resource ID parameter, choose AllocationId so that the runbook will remediate all noncompliant EIP addresses automatically.
    • Under Parameters, for AutomationAssumeRole, enter the ARN of your Automation service role.

Choose remediation action, Rate Limits, Resource ID parameter, and Parameters fields are completed as described in the procedure.

Figure 13: eip-attached

  1. To remediate the dynamodb-ptr-enabled config rule:
    • Under Select remediation, choose Automatic remediation. Leave the defaults for Retries in (5) and Seconds (60).
    • For Choose remediation action, select AWSConfigRemediation-EnablePITRForDynamoDBTable.
    • Under Rate limits, for Concurrent Execution Rate, enter 25. For Error Rate, enter 35.
    • Under Resource ID parameter, choose TableName so that the runbook will remediate all noncompliant DynamoDB tables automatically.
    • Under Parameters, for AutomationAssumeRole, enter the ARN of your Automation service role.

Remediation action details, Rate Limits, Resource ID parameter, and Parameters are completed as described in the procedure.

Figure 14: dynamodb-ptr-enabled

You have now successfully remediated all noncompliant AWS Config rules by using Automation runbooks.

The Remediation action column of the Rules table, which previously displayed Not set for each rule, now displays AWS-ConfigureS3BucketVersioning, AWS-EnableS3BucketEncryption, AWSConfigRemediation-EnableRDSInstanceDeletionProtection, AWS-ReleaseElasticIP, and AWSConfigRemediation-EnablePTRForDynamoDbTable.

Figure 15: Successful remediation of noncompliant AWS Config rules

Conclusion

In this blog post, I showed you how to use Automation runbooks to remediate noncompliant AWS Config rules automatically, without any manual intervention. With the information in this post, you can now build and remediate your own AWS Config rules. For more information about AWS Systems Manager features, see the AWS Systems Manager User Guide.

About the author

Raghavarao Sodabathina

Raghavarao Sodabathina

Raghavarao Sodabathina is an Enterprise Solutions Architect at AWS. His areas of focus are data analytics, AI/ML, and the serverless platform. He engages with customers to create innovative solutions that address customer business problems and accelerate the adoption of AWS services. In his spare time, Raghavarao enjoys spending time with his family, reading books, and watching movies.