Announcing AWS Config Custom Rules using Guard Custom policy

AWS Config lets you evaluate your AWS resources with a desired configuration state using AWS Config Rules. In AWS Config, you can define two types of rules, managed rules and custom rules. Managed rules are AWS provided rules that will evaluate your resources with a predefined configuration state that address some of the most common use cases for customers. On the other hand, custom rules let you define the custom logic of your desired configuration state for your resources. Until recently, you could only create a custom rule by defining an AWS Lambda function that included your custom logic to evaluate your resources against your desired configuration state. However, customers wanted a simpler way to write custom logic without needing to develop Lambda functions to manage their custom rules.

Today, we’re excited to announce the general availability of a new feature within AWS Config to allow for the creation of custom rules using Guard Custom policy. Guard Custom policy can help simplify the process of creating custom rules, since you won’t need to create your own Lambda functions. Guard Custom policy lets you define your policy-as-code to evaluate your resource against the policy that’s defined using the Guard domain-specific language (DSL).

For example, let’s imagine that you were just hired as a compliance specialist, and you would like to build a few custom rules based on the controls that your organization has defined for compliance. However, you find it difficult to write custom rules that need a Lambda function written in languages such as Java or Python. This is where using Guard Custom policy can help. You can create an AWS Config custom rule using Guard DSL without needing to develop Lambda functions to manage your custom rules.

Let’s look at how to create two example controls using the Guard DSL. We’ll create one control that evaluates if an Amazon Elastic Compute Cloud (Amazon EC2) instance has a public Elastic IP attached and running. Then, we’ll define a second control to evaluate Amazon Elastic Block Store (Amazon EBS) volumes and check if they have a defined IOPS setting. I’ll show you just how simple it is to create these custom rules using the Guard Custom Policy language.

Creating a custom rule using Guard Custom policy

One of the controls that we must implement is to create a custom rule that will evaluate an Amazon EC2 instance, as well as check if it has an Elastic IP and that it’s currently in a running state. Let’s look at how we can do this by using a Guard Custom policy rule.

1. Go to the AWS Config console, and then select Rules on the left side of the console.
2. Select Add Rule.
3. In the Select rule type screen, select Create custom rule using Guard, and select Next.

Figure 1: AWS Config Specify Rule Type

4. Under the Details section, enter ec2-eip-state for the Name.
5. Optionally, you can check Enable debug logs box to send rule debug logs to Amazon CloudWatch Logs. AWS Config will create a log group in the format of /aws/config/config-rule/<ConfigRuleName>/<ConfigRuleId>, and send debug logs for each evaluation of this config rule. The debug logs provide details about an evaluation of your policy. For example, it indicates in a single evaluation, which rules in the Guard Custom policy are not_applicable, compliant, and not_compliant with detailed reasons.

Figure 2: AWS Config Configure Custom Guard Rule.

6. In the Rule Content section, enter the following Guard Custom policy.

let eipresource = relationships.*[ resourceType  == 'AWS::EC2::EIP' ]

rule check_ec2_eip_compliance {
    when %eipresource !empty {
    configuration.state.name == "running"
}
}

Figure 3: AWS Config Rule Content for Custom Guard Rule

7. In the Trigger section, select Resources, and choose AWS EC2 Instance.

Figure 4: AWS Config Select Trigger Scope and Resources

8. The rest of the parameters can be left as default, and you can select Next.
9. Under the Review and create section, select Add rule.

In this example, you created a Guard Custom policy rule that will evaluate Amazon EC2 instance resources. For any Amazon EC2 instances with an Elastic IP attached, the rule will validate if the instance is in a running state. If the Amazon EC2 instance is not in a running state, then the rule will mark the Amazon EC2 resource as noncompliant.

Creating a custom rule using a parameter for Guard Custom policy

Let’s look at the second control that we must implement. We must create a control that evaluates Amazon EBS volumes against a desired IOPS value. Furthermore, we need to allow the ability to define the Amazon EBS volume type using a parameter. Let’s look at how we can do this by using a Guard Custom policy rule.

1. Go to the AWS Config console, and then select Rules on the left side of the console.
2. Select Add Rule.
3. In the Select rule type screen, select Create custom rule using Guard, and select Next.

Figure 5: AWS Config Specify Rule Type

4. Under the Details section, enter ebs-volume-iops for the Name.
5. Optionally, you can check Enable debug logs box to send rule debug logs to Amazon CloudWatch Logs. AWS Config will create a log group in the format of /aws/config/config-rule/<ConfigRuleName>/<ConfigRuleId>, and send debug logs for each evaluation of this config rule. The debug logs provide details about an evaluation of your policy. For example, it indicates in a single evaluation, which rules in the Guard Custom policy are not_applicable, compliant, and not_compliant with detailed reasons.

Figure 6: AWS Config Configure Custom Gurad Rule

6. In the Rule Content section, enter the following Guard DSL policy:

rule desiredebsvolumeiops {
  when configuration.volumeType == CONFIG_RULE_PARAMETERS.volumeType {
    configuration.iops in [3000,4000]
  }
}

Figure 7: AWS Config Rule Content for Custom Guard Rule

7. In the Trigger section, select Resources, and choose AWS EC2 Volume.

Figure 8: AWS Config Select Trigger Scope and Resources

8. In the Parameters section, enter volumeType for Key and gp3 for Value.

Figure 9: AWS Config Parameters Screen

9. In the Guard Custom policy rule, this parameter is referenced as “CONFIG_RULE_PARAMETERS.volumeType” within the DSL code.
10. The rest of the parameters can be left as default, and you can select Next
11. Under the Review and create section, select Add rule.

In this example, you created a Guard Custom policy rule to evaluate Amazon EBS volumes that specify a volume type based on a rule parameter. Then, the rule will validate if the Amazon EBS volume IOPS are set to either 3000 or 4000. If not, the rule will mark the resource as noncompliant.

Creating a Guard Custom policy using the AWS Command Line Interface

Perhaps you must implement this Guard Custom policy using the AWS Command Line Interface (AWS CLI) tools. This can be useful if you need to deploy Guard Custom policy in an automated approach, such as within a script or CI/CD pipeline. Let’s look at how you can deploy the rule that you just created in the previous section, but by using the AWS CLI tools.

1. Create a JSON document named ebs-volume-iops-cli-version.json containing the following JSON-provided values.

{
"ConfigRuleName": "ebs-volume-iops-cli-version",
"Description": "Evaluates whether EBS volumes have a specific IOPs setting.",
"Scope": {
    "ComplianceResourceTypes": [
        "AWS::EC2::Volume"
    ]
},
"Source": {
     "Owner": "CUSTOM_POLICY",
     "SourceDetails": [
         {
             "EventSource": "aws.config",
             "MessageType": "ConfigurationItemChangeNotification"
         },
         {
             "EventSource": "aws.config",
             "MessageType": "OversizedConfigurationItemChangeNotification"
         }
      ],
      "CustomPolicyDetails": {
          "PolicyRuntime": "guard-2.x.x",
          "PolicyText": "rule desiredebsvolumeiops { when configuration.volumeType == CONFIG_RULE_PARAMETERS.volumeType { configuration.iops in [3000,4000]}}",
          "EnableDebugLogDelivery": false
       }
    },
    "InputParameters": "{\"volumeType\":\"gp3\"}"
}

2. Then, using the AWS CLI, run the following command:

aws configservice put-config-rule --config-rule file://ebs-volume-iops-cli-version.json

In this example, you  saw how you can use the AWS CLI command to create a Guard Custom policy. Similarly, you can create a Guard Custom policy using the PutConfigRule API, which you  can also use within a AWS Systems Manager Automation document to automate the steps for creating a Guard Custom policy rule.

Generally available today

You can begin creating your Custom Policy Rules using Guard DSL within the AWS Config console by using the AWS Software Development Kits (SDKs), or by using the AWS CLI. To get started, see the Writing AWS CloudFormation Guard rules in the AWS CloudFormation Guard Guide.

Cleanup

If you no longer want to use the Guard Custom policy that you deployed, then you can delete these rules by following these steps.

1. Go to the AWS Config console, and then select Rules on the left side of the console.
2. Select the ec2-eip-state rule, and select Actions | Delete rule.
3. Under the Delete confirmation box, type Delete, and select Delete.
4. Select the ebs-volume-iops rule, and select Actions | Delete rule.
5. Under the Delete confirmation box, type Delete, and select Delete.
6. Select the ebs-volume-iops-cli-version rule, and select Actions | Delete rule.
7. Under the Delete confirmation box, type Delete, and select Delete.

Conclusion

In this post, I’ve shown you some examples of how to use Guard Custom policy to create custom AWS Config rules using the Guard DSL language. I have also provided an example of how to leverage parameters in your Guard Custom Policy rule. Furthermore, we explored how to use the AWS CLI to create a Custom Policy Rule. This new feature for creating custom AWS Config rules using a Custom Guard Policy will let you create various rules using the Guard DSL to evaluate your resources recorded by AWS Config.

Author: