Custom Best Practices allow you to assign Config Rules and Lambda functions to your AWS accounts to detect configurations in your environment.
This topic will:
provide a high-level summary of how custom best practices work
describe the role of AWS config rules
describe the role of AWS Lambda functions
describe the role of built-in config rules
describe the role of the Deploy button
describe how to deploy built-in config rules
describe the role of the custom config rules
describe how to create and deploy custom config rules
describe how to undeploy a custom config rule
describe how to package AWS Lambda functions
Click a a button to learn more.
AWS Config Rules invoke a given Lambda function on a periodic basis, such as every 24 hours, or on a configuration change such as a modification to a security group or the creation of an instance.
The AWS Lambda pulls data from the Amazon API to see a specific configuration setup. If AWS Lambda determines that a configuration is invalid, it will publish it to the AWS Config Rule as non-compliant. Our application then pulls down the non-compliant
results during the Discovery job and adds that as a new tab in the Best Practices report.
An
AWS Config Rule can detect configurations in your environment. The AWS Config Rule invokes a defined Lambda function on a periodic basis and/or on a change to a resource, such as a security group, Dynamo Table, NACL, or other resource. For a full
list, go the
AWS Config Resource Types topic.
AWS Config Rules also include compliance status—entities that did or did not pass compliance. The Lambda function associated with the AWS Config Rule generates the compliance results. Each Lambda invocation wipes out the current compliance statuses and
replaces them with the most recently invoked Lambda function.
Lambda is a server-less code execution service that:
uses Amazon’s API to gather a list of current configurations in the account
has logic to determine what entities are compliant and non-compliant
publishes the compliant and non-compliant entities to the AWS Config Rules using the
PutEvaluations API call
For example, if you need to find all security groups with open ports:
call DescribeSecurityGroups
break the security groups into two collections: one for compliant security groups with no ports open and another for non-compliant with one or more ports open
publish the collection compliant and non-compliant results to config using the
PutEvaluations API call using the passed rule ID
When the page first loads, the Built-in Config Rules tab displays and shows a list of built-in config rules you can deploy to your AWS account.
Each config rule element represents a config rule configuration that exists in your AWS account for each of the regions you saved. You can click each element to expand to see the details and configure the following elements of the built-in rule:
config rule name
Lambda function name
role to use for the Lambda function
memory, timeout, and VPC of the lambda function
You must select a role before you deploy.
CloudCheckr provides C#-based Lambda functions. All parameters are disabled except for Names, Role, and Advanced Lambda settings.
There are currently three built-in config rules that you can deploy to your AWS account:
Config Rule
Description
IAM Permissions
Lambda Package
cloudtrail-enabled
Scans region to see if CloudTrail is enabled and logging.
The Deploy button marks the selected config rule for deployment, which applies the config rule and Lambda function to the AWS account associated with your Cloudcheckr account. CloudCheckr dispatches a back-end job to fulfill the request.
The job enumerates each of your saved regions and applies a Lambda function to your AWS account and a config rule associated with the previous Lambda function.
This procedure shows you how to deploy a Built-In Config rule using the cloudtrail-enabled rule as an example.
From the left navigation pane, choose Security > Custom Best Practices to open the Custom Best Practices page.
Click the cloudtrail-enabled rule to expand the rule and see the parameters.
Click Update Config Rule.
A pop-up message indicates that the application updated the rule.
Click OK.
Click Deploy.
A pop-up message indicates that the application deployed the rule.
Click OK.
After the page refreshes, click the cloudtrail-enabled rule to expand the rule and see the event log.
The event log shows that the application successfully deployed the rule.
From the left navigation pane, choose Best Practices to verify that the Custom (via Config Rules) tab exists.
Repeat the procedure for the mfa-enabled and the security-groups-with-open-ports rules.
If the Deploy button for a selected rule is not enabled:
Click Undeploy.
A pop-up prompts you to confirm the undeployment of the AWS Config Rule.
Select the Delete underlying Lambda Functions as well? checkbox and click Delete.
A pop-up message indicates that the application undeployed the rule and the Lambda function.
Click OK.
From the left navigation pane, choose Security > Custom Best Practices.
Click the rule to expand the rule and see the parameters.
Change the name of the rule and the name in the Lambda Function section.
Click Update Config Rule.
Click OK.
Once the button is enabled, click Deploy.
The second tab on the Custom Best Practices page is the Custom Config Rules tab where you can create a new config rule and give it a custom Lambda package. The Lambda package must follow the basic structure outlined in the AWS Lambda section:
Name: config rule you are applying to the AWS account
Description: description of the config rule
Trigger:
Trigger Type: when the config rule invokes the Lambda
Applied Regions: the region where you apply the config rule and Lambda function
Scope of changes: applicable if you specify the Configuration Changes trigger type
Resources: trigger when a resource changes within a specific list of resource types and/or Resource ID
Tags: Trigger when a resource with specific tag changes
All: Trigger when any resource is changed
Frequency
This procedure shows you how to deploy a Custom Config rule using the cloudtrail-enabled rule as an example.
On the Custom Best Practices page, click the + New Config Rule.
The Create New Config Rule dialog box opens.
Provide a unique name and description for the new config rule.
Click Trigger.
Select the Configuration changes and the Periodic checkboxes.
If you are trying to create a custom config rule for cloudtrail-enabled, click Rules Parameter and populate these fields with the following information:
Key: cloudWatchLogsLogGroupA | Value: leave blank
Key: s3BucketName | Value: leave blank
Key: snsTopicArn | Value: leave blank
Click Lambda Function.
Provide a unique name and description for the new config rule.
From the Runtime drop-down list, select one of the following coding languages supported by CloudCheckr: C# .NET Core 2.1, Java 8, or Python 2.7.
If you select Java 8, you must also click Advanced Settings and select the largest available memory size.
Click Function Package and Environment Variables.
Click Browse and add one of the Lambda packages that you want to associate with your custom rule.
Click Handler and Role.
In the Handler field, type the Handler associated with this rule:
For your Custom Config rule, choose the handler associated with your setup.
From the Role drop-down list, select the role you want to associate with your Custom Config Rule.
Click the Apply Rule To Account button.
As a CloudCheckr customer, you want the flexibility and control to create, deploy, or undeploy custom best practice checks at your discretion.
When you create and deploy a CloudCheckr custom best practice check, AWS creates an AWS Config rule in the AWS account associated with your CloudCheckr account, which forms a dependency between CloudCheckr and the AWS Lambda functions.
Before you undeploy a custom config rule, you must decide if you want to break or retain that dependency between CloudCheckr and the AWS Lambda functions.
This procedure describes why you would want to break or retain the AWS/CloudCheckr dependency and how to undeploy your custom config rule.
On the Custom Best Practices page, click the Custom Config Rules tab.
Click Undeploy for a selected custom config rule.
A pop-up prompts you to confirm the undeployment of the custom config rule.
Determine if you need to select the Delete underlying Lambda Functions as well? checkbox:
Select if you want to permanently break the connection between the custom config rule and the Lambda functions. This action will undeploy the custom config rule but will not delete the Lambda functions so you can rename and redeploy
the custom config rule successfully. This option is recommended.
Do not select if you want to retain the connection between the custom config rule and the AWS Lambda functions for future use.
Click Delete.
If you selected the Delete underlying Lambda Functions as well? checkbox, a pop-up message indicates that the application marked the rule and the Lambda functions for undeployment.
If you did not select the Delete underlying Lambda Functions as well? checkbox, a pop-up message indicates that the application only marked the rule for undeployment.
