How To Use AWS Config
In our lab walkthrough series, we go through selected lab exercises on our INE Platform. Subscribe or sign up for a 7-day, risk-free trial with INE and access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!
Purpose:
It is crucial to monitor how the resources you have been creating in your AWS account are configured. What if there was a mechanism to identify resources that were not configured in accordance with the rules? Here, AWS Config becomes handy. In this article, we will learn how to use AWS Config to construct various rules that will identify resources that do not adhere to the rules specified in the AWS Config.
Technical difficulty:
| Novice | Beginner | Competent | Proficient | Expert
What Is AWS Config?
AWS Config displays a detailed view of the AWS resource configuration in your AWS account (an AWS resource is an entity you can work with in AWS, such EC2, EBS, or VPC). This covers how the resources are tied to one another as well as how they were previously configured, allowing you to examine how the configurations and relationships change over time.
We use AWS Config to evaluate the configuration settings of your AWS resources. You do this by creating AWS Config rules, which represent your ideal configuration settings. AWS Config continuously tracks the configuration changes that occur among your resources, and checks whether these changes violate any of the conditions in your rules. If a resource violates a rule, AWS Config flags the resource and the rule as noncompliant otherwise compliant.
AWS Config Rules are of two types:
AWS Config Managed Rules
AWS Config Custom Rules
AWS Config Managed Rules are predefined, customizable rules that AWS Config uses to evaluate whether your AWS resources comply with common best practices or not. You can set up and activate these rules without writing the code to create an AWS Lambda function, which is required if you want to create custom rules.
AWS Config Custom Rules: We use Guard Custom policy or Lambda functions to develop Custom Policy Rules or Custom Lambda Rules and add them to AWS Config to create the AWS Config custom rules.
NOTE: Guard is a policy-as-code language that allows you to write policies that are enforced by AWS Config Custom Policy rules. Rules written using Guard can be created from the AWS Config console or by using the AWS Config rule APIs.
Custom Policy rules allow you to create AWS Config Custom rules without needing to use Java or Python to develop Lambda functions to manage your custom rules. And these are initiated by configuration changes.
Custom Lambda rules provide you with the option to use Java or Python to create a Lambda function for a AWS Config Custom rule. If the Lambda function is associated with an AWS Config rule, AWS Config invokes it when the rule is initiated. The Lambda function then evaluates the configuration information that is sent by AWS Config, and it returns the evaluation results.
Now that we have covered all the key terms for the lab, let's carry out the experiment.
Lab Scenario
We have set up the below scenario in our INE labs for our students to practice. The screenshots have been taken from our online lab environment.
Lab Link: AWS Config
Objective
Create AWS Config rules and check whether the created resources are compliant or non-compliant.
Solution
Step 1: Click the lab link button to get access credentials. Login to the AWS account with these credentials.
Step 2: Search for Config in the search bar and navigate to the Config dashboard.
Step 3: Click on the “Get Started” button.
After setting up, AWS Config will evaluate your AWS resources against the rules that you chose. Additional rules can be created and existing ones can be updated and in your account after setup.
Step 4: Choose type to record as “Record all resources supported in this region” and set AWS Config rule as “Create AWS Config service-linked role”.
AWS Config records configuration changes for supported AWS resource types as well as third-party resource types registered in the AWS CloudFormation registry. AWS Config automatically starts recording new supported AWS resource types.
Service-linked roles are predefined by AWS Config and include all the permissions that the service requires to call other AWS services.
Step 5: Choose “Create a bucket” and use the default bucket name.
Step 6: Create a Config rule. Search for “EC2” in AWS Managed rules. Managed rules are predefined, customizable rules created by AWS Config.
Select “ec2-imdsv2-check” and “ec2-instance-no-public-ip”..
Select “ec2-instance-profile-attached” and scroll to the bottom.
Select “ec2-volume-inuse-check” and “restricted-ssh”.
Step 7: Review the Config setup.
Step 8: Click on Confirm.
Now create a custom rule using lambda. To create this rule, first, you will create an AWS Lambda function by customizing a blueprint in the AWS Lambda console. Then, you will create a Custom Lambda rule in AWS Config, and you will associate the rule with the function.
Step 9: Search for “lambda” in the search bar and navigate to the Lambda dashboard.
Step 10: Click on the “Create function” button.
Step 11: Choose “Use a blueprint” and search for “config” in the blueprints filter and select “Config rule triggered by EC2 configuration change”.
Step 12: Set function name as “ec2-config-change” and choose “Create a new role from AWS policy templates” as execution role and set role name as “ec2-config-change-role”. Use the default policy for policy templates.
Step 13: Click on the “Create function” button.
Step 14: Check out the source code in index.js file. Here you can customize the code according to your need.
Step 15: Copy the function ARN.
Step 16: Click on the “Add rule” button.
Step 17: Select rule type as “Create custom Lambda rule”. Click on the “Next” button.
Step 18: Set rule name as “ec2-change-rule”. Paste the copied lambda function ARN.
Step 19: Set the trigger type as “When configuration changes'' and scope of change as Resources. Set Resource category as “All resource categories” and Select “AWS EC2 Instance”, “AWS EC2 RouteTable”, “AWS EC2 Subnet”,”AWS EC2 VPC”, ”AWS EC2 NetworkInterface” as resources type.
AWS Config triggers the evaluation when any resource that matches the rule's scope changes in configuration. The evaluation runs after AWS Config sends a configuration item change notification.
Step 20: Click on the “Next” button.
Review the Config settings.
Step 21: Click on the “Add rule” button.
Successfully created the custom lambda Config rule.
Step 22: Again, click on the “Add rule” button. Now add a custom rule using Guard.
Step 23: Set rule type as “Create custom rule using Guard” and click on “Next” button.
Step 24: Set rule name as “check_ec2_eip_compliance”. Set Guard runtime version as “guard-2.x.x”
Guard is a policy-as-code language that allows you to write policies that are enforced by AWS Config Custom Policy rules. Rules written using Guard can be created from the AWS Config console or by using the AWS Config rule APIs. AWS Config Custom Policy rules allow you to create AWS Config Custom rules without needing to use Java or Python to develop Lambda functions to manage your custom rules.
Step 25: Copy and paste the below code. This code will validate if any EC2 instances with an Elastic IP attached, are in a running state. If the EC2 instance is not in a running state, then the rule will mark the Amazon EC2 resource as non-compliant.
Code:
let eipresource = relationships.*[ resourceType == 'AWS::EC2::EIP' ]
rule check_ec2_eip_compliance {
when %eipresource !empty {
configuration.state.name == "running"
}
}
Step 26: Set scope of changes as “Resources” and select “AWS EC2 Instance” in the resource type.
Step 27: Click on the “Next” button.
Review the Config rule settings.
Step 28: Click on the “Add rule” button.
All the rules are created successfully. Now create resources and check out the working of AWS Config.
Step 29: Search for “EC2” in the search bar and navigate to EC2 Dashboard.
Step 30: Click on the “Launch Instance” button.
Step 31: Set Instance name as “lab-instance” and select “Amazon Linux” as AMI.
Step 32: Choose Instance type as “t2-micro” and proceed without a key pair.
Step 33: Select “Create security group” and set “Allow SSH traffic from anywhere”.
Step 34: In the Advanced details , make Metadata accessibility “Enabled” and set “V2 only (token required)” for Metadata version.
Step 35: Click on the “Launch instance” button.
Successfully created an instance.
Step 36: Click on “Elastic IPs” from the navigation pane.
Step 37: Click on the “Allocate Elastic IP address” button.
Step 38: Set public IPv4 address pool as “Amazon’s pool of IPv4 addresses”.
Step 39: Click on the “Allocate” button.
Step 40: Select the allocated IP address and click on “Associate Elastic IP address” under the actions button.
Step 41: Choose the created instance id and allocated IP address.
Step 42: Click on the “Associate” button.
Step 43: Click on “Instances” from the navigation pane.
Elastic IP will be available for instance.
Step 44: Click on “Stop instance” under Instance state.
Click on the “Stop” button and confirm the action.
Step 45: Navigate back to AWS Config dashboard and check the created rules for compliance.
Step 46: Click on “ec2-instance-profile-attached” .
Checks if an EC2 instance has an IAM profile attached to it. This rule is NON_COMPLIANT if no IAM profile is attached to the EC2 instance.
Resource in scope is an EC2 Instance with ID “I-0621bb7af28e498c8”. This shows that this EC2 instance does not have an IAM profile attached to it.
Step 47: Click on “check_ec2_eip_compliance”. This rule will validate if any EC2 instances with an Elastic IP attached, are in a running state. If the EC2 instance is not in a running state, then the rule will mark the Amazon EC2 resource as non-compliant.
Resource in scope is an EC2 Instance with ID “I-0621bb7af28e498c8”. An EC2 instance with an Elastic IP attached is not in a running state.
Step 48: Click on “ec2-volume-inuse-check”. Checks if EBS volumes are attached to EC2 instances. Optionally checks if EBS volumes are marked for deletion when an instance is terminated.
Step 49: Click on “restricted-ssh”. Checks if the incoming SSH traffic for the security groups is accessible. The rule is COMPLIANT when IP addresses of the incoming SSH traffic in the security groups are restricted (CIDR other than 0.0.0.0/0). This rule applies only to IPv4.
Resource in scope is an EC2 Instance with ID “I-0621bb7af28e498c8”. This shows that SSH traffic in the security group is not restricted.
Step 50: Click on “ec2-change-rule”. This rule will check if there are any changes performed in EC2 instance configuration. If the EC2 instance has any change in configurations, then the rule will mark the EC2 resource as non-compliant.
Resource in scope is an EC2 Instance with ID “I-0621bb7af28e498c8”. This shows that the instance running had some changes in configuration.
Step 51: Click on “ec2-imdsv2-check”. This rule checks whether your Amazon Elastic Compute Cloud (Amazon EC2) instance metadata version is configured with Instance Metadata Service Version 2 (IMDSv2). The rule is NON_COMPLIANT if the HttpTokens is set to optional.
This rule is compliant as we have enabled IMDSv2 for this instance.
Step 52: Click on “ec2-instance-no-public-ip”. This rule checks whether EC2 instances have a public IP association. The rule is NON_COMPLIANT if the publicIp field is present in the Amazon EC2 instance configuration item. This rule applies only to IPv4.
Resource in scope is an EC2 Instance with ID “I-0621bb7af28e498c8”. This shows that this instance does not have a public IP association.
Step 53: Click on “Dashboard” from the navigation pane.
Resource inventory will provide the count of resources active in the AWS account.
There are no conformance packs deployed.
A conformance pack is a collection of AWS Config rules and remediation actions that can be easily deployed as a single entity in an account and a Region or across an organization in AWS Organizations.
Step 54: Click on “Conformance packs” from the navigation pane.
Step 55: Click on the “Deploy conformance pack” button.
Step 56: Select “Use sample template” for conformance pack template and choose “Operational Best Practices for EC2”.
Step 57: Set conformance name as “ec2-conformance-pack”.
Step 58: Click on the “Next” button.
Review the conformance pack configurations.
Step 59: Click on the “Deploy conformance pack” button.
Step 60: Click on “ec2-conformance-pack”.
It will list all the rules available inside the conformance pack.
Step 61: Click on “Rules” from the navigation pane.
Check out the compliance for all the created rules.
References:
Conclusion
Congratulations! We successfully learnt how to create the AWS Config rules and check whether the created resources are compliant or non-compliant.
Try out AWS Config hands-on in our lab! Subscribe or sign up for a 7-day, risk-free trial with INE to access this lab and a robust library covering the latest in Cyber Security, Networking, Cloud, and Data Science!
