AWS Config Rules. An AWS Config Rule defines your desired state in terms of configuration for a resource. AWS Config evaluates resource configurations and marks them as compliant or non-compliant with the rules that you have defined. Creating a rule should not be difficult, and that is because AWS provides you with over 320 different managed rules for you to use as-is or customize them to suit your needs. You can review the list of AWS Config Managed Rules by visiting the URL shown. As you examine the list, you will notice the variety of rules. In our example, we chose three rules to use and verify some of the resources that we have prefabricated. The first is the eip-attached rule. This is an EC2 instance rule that checks to see if all elastic IP addresses that are allocated are also attached to EC2 instances or used in elastic network interfaces.

The rule is NON_COMPLIANT if the AssociationID for the Elastic IP address is null. This means that it's allocated but not being used and therefore, there will be an expense associated with it for a resource that is not rendering any benefit. In a similar way, in our example, we chose the ec2-volume-inuse-check rule. This is a rule to verify if an EBS volume that has been created is attached to an EC2 instance. An unattached EBS volume represents a resource not delivering any benefit and must be backed up and deleted if possible. Finally, we also selected the restricted-ssh rule which checks if security groups that are in use do not allow unrestricted incoming SSH traffic. This is a security best practice and SSH access should be limited to specific IPs or even better, be eliminated completely in favor of using Systems Manager Session Manager to securely connect to your instances. Suffice it to say, you will probably start with an AWS Managed rule and use it as-is. Existing AWS-managed rules cover over 55 AWS services. Finding a rule that you will need should not be difficult and modifying an existent rule is relatively easy.

In addition to the variety of AWS-managed rules, you can create your own custom rules. First, you can create a custom Lambda rule and add it to AWS Config. The idea here is that you associate the custom rule with a Lambda function, which will implement the logic that evaluates if the resource is compliant or not. AWS Config invokes the function when the rule's triggers happen. The AWS Lambda console provides blueprints which you can customize by adding your own logic to create a Lambda function for a custom Config rule. These templates are called config-rule-change-triggered, which is triggered when your AWS resource configurations change. And the second one is called config-rule-periodic, which is triggered at a frequency that you define. There's also a custom Lambda rules repository available on GitHub at the URL displayed github.com/awslabs /aws-config-rules/. There's a significant amount of examples there provided by the AWS community of developers. If Lambda functions are not part of your day-to-day affairs, but the AWS Command Line Interface is, then the AWS Config Rule Development Kit or RDK can simplify your custom rule development experience. The RDK is an open-source tool that helps you set up AWS Config, author rules, and test them.

The AWS Config RDK requires the latest version of the AWS CLI being installed and configured. You can then use the command shown to clone the AWS Config RDK for macOS, Linux, or Windows. Please note that in the background, what the RDK is doing is generating a custom AWS Lambda rule. The AWS Config RDK lets you test your rule by invoking the Lambda function with configuration items used as test cases from prefabricated directories that are listed with compliant configuration items and non-compliant configuration items as examples. The RDK checks that the Lambda function returns the corresponding result. In addition to custom Lambda Rules, you can create a custom rule using AWS CloudFormation Guard. CloudFormation Guard is a policy-as-code evaluation tool that is open-source and uses a domain-specific language or DSL. Using the Guard CLI, you can define policy as code. You will need to install the custom Guard CLI in order to use it, which also includes a unit testing framework for you to verify the rules work as expected. Guard rules are built using clauses, and a clause is simply a boolean expression that evaluates to true or false. For example, the display clause evaluates if the ReadCapacityUnits property in a DynamoDB table is less than or equal to 5000.

Take a closer look. Using CloudFormation Guard rules, you can validate CloudFormation templates, CloudFormation Change sets, JSON based Terraform configuration files, and Kubernetes configurations. Using CloudFormation Guard can ensure that changes are safe before deployment, providing you a pro-active mechanism for verifying compliance of infrastructure-as-code resources like CloudFormation templates. Guard Rules use their very own Domain Specific Language or DSL and require a custom CLI to be used. The latest major version of Guard is version 2.1 and was released in June of 2022. If you are already using CloudFormation Guard rules, AWS recommends you migrate to the most recent version because it includes significant enhancements to the developer experience. In addition to improving the stability and performance of CloudFormation Guard or CFN-Guard for short as it is called commonly. Using version 2.1, you have the option of viewing a color-coded output that highlights code snippets on failure, giving you better visibility of what corrective actions to take. You also get the ability to write rules that use parameters to create rules that work across CloudFormation templates, Terraform plans, and AWS Config instead of using separate templates for each.

CloudFormation Guard provides a simple Policy-as-code language to define rules that can check for both required and prohibited resource configurations. For details, please visit the cfn-guard documentation or the cfn-guard GitHub Repository at the URL shown. Selecting or defining a rule will not be useful, unless we also configure the rule for evaluation mode. A rule's evaluation mode defines when resources will be evaluated by the rule, and there are a few options to choose from. First, you can select Proactive Evaluation, which enables evaluation of resources prior to provisioning. You can also select Detective Evaluation, which enables evaluation of resources that already exist. This is very useful when we're getting started to use AWS Config. The second step after choosing evaluation mode relates to defining the trigger. This tells AWS Config to evaluate resources when the trigger happens. You can choose a trigger type when configuration changes take place on the resources, or you can choose to run an evaluation based on the frequency that you want in hours. The trigger kicks the evaluation into action. If you choose a trigger type of, When configuration changes, you'll also need to specify the scope of changes that will cause the trigger to be issued. You can choose, All changes, which will trigger when any resource recorded by AWS Config is created, changed, or deleted. This is the most general of triggers and will cause an evaluation of resources with any modification to your implementation.

You can also focus the scope a bit and issue the trigger when any resource that matches your specified type is created, changed, or deleted. This is useful if you're particularly monitoring the configuration of a specific resource type, like security groups, for example. Finally, you can specify the trigger to be issued when any resource with a specified tag is created, changed, or deleted. If you have implemented a Tag Culture in the provisioning of your AWS resources, this trigger can be very useful. As a small but very important detail, some rules will need you to define parameters. They are used for values that are required for a rule to do its evaluation. For example, the access-keys-rotated managed rule includes a parameter called maxAccessKeyAge as a required parameter. The default value is in 90 days. If a Managed Rule includes parameters, it becomes essential that you pay attention to this detail and configure the value as needed for which your resources will be evaluated. The very last item in configuring a rule are the optional tags in key-value pairs. As your implementation grows, a tag mechanism and a Tag Culture becomes essential to be able to group resources based on your business categories.

AWS Config Rules

About