Manage custom AWS Config rules with remediations using conformance packs

Different organizations have different compliance and security requirements for their resources and accounts. AWS Config makes it easier for customers to implement these controls. While AWS Config offers customers a wide selection of managed AWS Config rules that help them comply with their requirements, there are customers who require more customized control and can take advantage of building their own custom AWS Config rules as well as custom remediations.

Once those rules have been configured, customers want a way to scale out their rules to their AWS Organizations and deploy the rules using organization-wide deployment while still maintaining control of the rules themselves at the master account level. The new feature, conformance packs, allows customers to create a collection of AWS Config rules and remediations in a single pack that can be deployed across an AWS Organization.

This blog post demonstrates how customers can use conformance packs to deploy custom AWS Config rules with custom remediation across their organizations.

Overview of solution

This blog post goes over deploying custom AWS Config rules with custom remediation using conformance packs across an AWS Organization while keeping the custom rule’s AWS Lambda function in the master account. The custom AWS Config rule checks if there are any Security Groups with a rule that allows access for a CIDR block larger than /16. This means that any Security Group rule added that is larger—10.0.0.0/10 or 10.0.0.0/1—makes the Security Group non-compliant. Once the custom AWS Config rule marks it as non-compliant, it triggers an SSM automation document that calls the remediation Lambda function that removes the non-compliant rule from the Security Group.

Walkthrough

This blog post goes over the following steps:

Deploy an AWS CloudFormation template in the master account that creates two Lambda functions—one for the AWS Config rule and one for remediation—as well as the appropriate IAM roles for cross-account execution in member accounts.
Deploy a StackSet to create IAM roles in the member accounts that are assumed by the Lambda functions in the master account.
Upload an SSM automation document that defines the remediation step for the custom AWS Config rule and share the SSM document with the member accounts in your AWS Organization.
Set up the prerequisites for conformance packs.
Deploy the conformance pack in your AWS Organization.

Prerequisites

For this walkthrough, you should have AWS Config enabled in all the accounts in your AWS Organization (you can enable it for all accounts in your AWS Organization using StackSets).

Deploying the AWS CloudFormation template

Click below to launch a new CloudFormation stack in your master account.

The stack creates two Lambda functions:

ConformancePackSecurityGroup: used as the custom AWS Config rule
AutomationSecurityGroupConformance: used for remediation

It also creates three IAM Roles:

LambdaExecutionRoleForConfig: assumed by the Lambda function ConformancePackSecurityGroup
AutomationLambda: assumed by the Lambda function AutomationSecurityGroupConformance
AutomationRole: used by the SSM automation document

Next, deploy a StackSet to create all the necessary IAM Roles in all the member accounts in the AWS Organization. Download this StackSet and deploy it from the master account. Make sure to put in your Master Account ID in the Parameters section of the StackSet as shown in the following screenshot:

Finally, deploy the StackSet.

The StackSet creates three IAM Roles in all member accounts:

LambdaExecutionRoleForConfig: assumed by the Lambda function ConformancePackSecurityGroup in the master account
AutomationLambda: assumed by the Lambda function AutomationSecurityGroupConformancein the master account
AutomationRole: used by the SSM automation document from the master account

The execution roles you create for the Lambda functions in the member account are extracted in the Lambda code in the master account, therefore the role name must be the same in all the member accounts.

Adding permissions for AWS Config to invoke Lambda

Run the following command to allow the AutomationSecurityGroupConformance function to be invoked by the AutomationRole in the member accounts. Change the Member Account ID to your member account (for multiple member accounts, run this command for each account number):

aws lambda add-permission --function-name AutomationSecurityGroupConformance --statement-id "AllowExecutionFromAutomation" --action "lambda:InvokeFunction" --principal "arn:aws:iam::{MemberAccount}:role/AutomationRole"

Creating an SSM document

The SSM automation document defines the automation remediation action that is taken when a resource is non-compliant.

Create the automation document:

Go to AWS Systems Manager and choose Automation, then Execute Automation, and then Create Automation. Name the remediation document SecurityGroupAutomation.
Change the mode to Editor and choose Edit. Paste the following in the content section:

{  
      "description": "Automation Document Example JSON Template",  
      "schemaVersion": "0.3",  
      "assumeRole": "{{ AutomationAssumeRole }}",  
      "parameters": {  
        "SecurityGroup": {  
          "type": "String",  
          "description": "{{ SecurityGroupID }}"  
        },  
        "AutomationAssumeRole": {  
          "type": "String",  
          "description": "The ARN of the role",  
          "default": ""  
        },  
        "MasterAccountID": {  
          "type": "String",  
          "description": "The Master Account ID",  
          "default": ""  
        }  
      },  
      "mainSteps": [  
        {  
          "name": "invokeMyLambdaFunction",  
          "action": "aws:invokeLambdaFunction",  
          "maxAttempts": 3,  
          "timeoutSeconds": 120,  
          "onFailure": "Abort",  
          "inputs": {  
            "FunctionName": "arn:aws:lambda:us-east-1:{{MasterAccountID}}:function:AutomationSecurityGroupConformance",  
            "Payload": "{\"parameterName\":\"SecurityGroup\", \"parameterValue\":\"{{SecurityGroup}}\", \"accountID\":\"{{global:ACCOUNT_ID}}\"}"  
          }  
        }  
      ]  
}

Sharing the SSM automation document with member accounts

Next, share the SSM automation document that defines your remediation action with all your member accounts.

Go to Systems Manager and select Automation, then go to the Automation Document you created for remediation.
Choose the Details
In the Permissions section, add the account IDs of all member accounts into which you are deploying the conformance packs, choose Add, and choose Save.

Setting up the conformance pack prerequisites

You need to set up the proper conformance pack prerequisites. Make sure to name the Amazon S3 bucket as specified in the Prerequisites for Organization Conformance Packs section.

Deploying the conformance pack

Nest, deploy the conformance pack through AWS CLI.

Download the conformance pack.
Open the conformance pack and change the Account ID to your Master Account IDin the three locations specified in the code, then save the conformance pack.
Copy the following command, and change the location of the template-body to the same location in which you saved the conformance packs template. Change the Amazon S3 bucket to the one you set up in the conformance pack prerequisites. Change the Region and Account ID to the Master Account ID for the Lambda function.
aws configservice put-organization-conformance-pack --organization-conformance-pack-name="conformancePack" --template-body=file://SecurityGroupConformancePack.yaml --delivery-s3-bucket={S3-bucket-for-conformance-pack} --conformance-pack-input-parameters=ParameterName=SecurityGroupMaskLambdaArn,ParameterValue="arn:aws:lambda:{region}:{MasterAccountID}:function:ConformancePackSecurityGroup"

Run the command after you make these changes. In all the member accounts in your AWS Organization, you are able to see the rule that you created.

Every time your member accounts make a change to a Security Group, the change is evaluated by the AWS Config rule. If it doesn’t comply with the /16 or smaller CIDR block range rule you built, the non-compliant rule is removed.

Testing the rule

Trigger a configuration change to a Security Group in a member account to test your rule.

In this example, you add a Security Group rule that has a source of 10.0.0.0/12, which doesn’t comply with your rule since it has a larger CIDR block range than /16. Therefore, it triggers your AWS Config rule as shown in the following screenshot:

The rule identifies the resource as “Non-compliant” and the remediation action execution starts, as shown in the following screenshot.

Once the Action Status for remediation is Action Executed Successfully, you can go back to the Security Group that was non-compliant, refresh the page, and see that the non-compliant rule has been removed, as shown in the following screenshot.

Cleanup

To remove all resources created as a part of this example, delete the following resources:

The AWS CloudFormation Stack in the master account
The StackSet in the master account
The SSM automation document

Run the following command to delete the conformance pack:

aws configservice delete-organization-conformance-pack --organization-conformance-pack-name conformancePack

Conclusion

This blog post demonstrated how you can use conformance packs to centrally manage custom AWS Config rules with custom remediation across your organization. To get started with AWS Config conformance packs visit our AWS Documentation.

About the Author

Shaked Rotlevi is a Solutions Architect working with Federal Government customers based in Washington DC. Shaked enjoys helping her customers implement AWS best practices and likes building new solutions on AWS. In her spare time, Shaked’s favorite acitivities include traveling and surfing.

AWS Cloud Operations & Migrations Blog