How to create custom AWS Config rules with AWS CodeStar

The AWS Config rules feature enables you to define in code the desired configuration of your AWS resources. For example, you can check that your Amazon S3 buckets are not publicly accessible or that your instances are associated with a security group.

While Config offers a set of prebuilt (managed) rules that represent common best practices, you may want to create custom rules to ensure that your AWS resources conform to your organization’s unique guidelines. You can define these guidelines in an AWS Lambda function that executes as your rule’s engine. For more information, see AWS Config Rules – Dynamic Compliance Checking for Cloud Resources.

AWS CodeStar is a centralized dashboard, from which you and your team can collaborate to develop, build, and deploy applications on AWS. AWS CodeStar includes project templates for common development platforms to enable provisioning of projects and resources for coding, building, testing, deploying, and running your software project.

In order to make the process of authoring Config rules easier, AWS CodeStar recently announced support for AWS Config custom rule templates, which allow you and your team to work together to define and author the set of Config rules that fit your organization. You can then deploy the necessary resources so that you have a working Config Rule at the click of a button.

In this blog, I show you how to author and create a custom Config rule using the AWS CodeStar end-to-end development experience.

Walkthrough
First, you need to record your AWS resources with Config. This means that Config records the configuration states of your resources whenever they are created or modified. Follow the steps in:

• Setting up AWS Config with the Console
• Setting up AWS Config with the AWS CLI

Now, get started creating your Config rule. For this example, you will write a rule to check that the S3 buckets in your account have versioning enabled. Luckily, this is already a managed rule, but for this example, pretend it isn’t.

In the AWS CodeStar console, start a project with the Config rule project template, selecting either Python or Node.js to author your rule.

This example will use Python, but the steps will be the same for Node.js. Click through until you get to the rule’s project dashboard. Use AWS CodeCommit as the code repository and AWS Cloud9 as the IDE. Here’s what the AWS CodeStar dashboard looks like upon arrival.

The AWS CodeStar dashboard is a one-stop-shop for the entire development process for your Config rule. It has links to AWS Cloud9, CodeCommit, AWS CodeBuild, AWS CodePipeline, and AWS CodeDeploy, as well as the permissions to access this project and the resources that this project creates.

First, open the link to the AWS Cloud9 IDE to author your rule.

Inside the IDE, you see the project directory with the code for the example rule and the AWS CloudFormation template to be used create the Config rule and Lambda function for this project. The rule’s code is separated into two files:

• The rule_util file handles the API calls to report evaluations back to Config (you won’t need to modify this file).
• The rule_code file comprises the actual logic of the rule.

If you open up the rule_code file, you can modify the code to check if your S3 buckets have versioning enabled.

Modify the APPLICABLE_RESOURCES because you want this rule to only report evaluations for S3 buckets. Then, look in the Configuration Item that was sent by Config to this Lambda function to check if versioning is enabled. If it isn’t, return that this resource is noncompliant with this rule.

Now, make the necessary changes to your CloudFormation template.

Change the rule name to something more descriptive (like S3BucketVersioningEnabled), add a description for what the rule does, and change the scope of the rule to only apply to S3 buckets.

That’s it. At this point, you’ve made all the code changes you need to have a Config rule that checks that your S3 buckets have versioning enabled. Push the change and watch it go through all the related services. The AWS Cloud9 IDE has a terminal window open where you can push the code directly to your CodeCommit repository.

Now, navigate back to the AWS CodeStar dashboard.

Watch as the change is pushed into the CodeCommit repository. Afterwards, CodeBuild packages up the code that you wrote and stores it in an S3 bucket that was created by this AWS CodeStar project. Then, CodeDeploy takes that build from S3 and creates your Config rule backed by the Lambda function that you just wrote.

Also accessible from the dashboard is a link to the Config rule console where you can see your rule in action.

You can see that the Config rule evaluated all of your S3 buckets. Three of them are noncompliant, meaning versioning wasn’t enabled.

Conclusion
I hope this post has shown you how easy it is to use AWS CodeStar to create custom Config rules that verify the configurations of your AWS resources.

About the author:

Greg Kim is an engineer on AWS Config. In his spare time, he likes to play basketball, eat, and enjoy the sun when Seattle is in a giving mood.