By Carl Durrant, Senior Consultant, Avocado
In this three part series, I am taking you through Amazon Web Services (AWS) Config. It is a lesser known service from AWS but an incredibly powerful tool. In part one of the series, I went through how visibility is gained every time a configuration item is changed, the five features in which AWS Config is built upon and how to adapt it specifically to your needs.
In this second post, I am delving deeper into the key concepts of the service, the AWS Config timeline – my personal favourite part of this tool, and the rules for building up the base capability of recording all changes.
Key concepts
A Configuration Item is the core part of AWS Config. It is a point-in-time, representation of the configuration of a resource in AWS. It contains all the components that make-up a configuration item. There are five components that are captured in JSON format:
- Metadata – information about the Configuration Item such as Configuration Item ID, time when it was captured
- Common Attributes – resource attributes such as AWS Resource ID, AWS Resource Type
- Relationships – how the resource is related to other resources in the account i.e. EBS volume
- Current Configuration – information returned through a call to Describe or List API of the resource such as type of volume gp2 or standard
- Related events – the AWS CloudTrail events that are related to the current configuration of the resource i.e. AWS CloudTrail event ID (as GUID)
Once configured, AWS Config provides a resource inventory from which you can search for common resources. You can search for resources by tags, for example, if you wanted to show all items tagged under “production”. You start to then understand how powerful this tool can become from an audit and compliance perspective.
AWS Config timeline
As mentioned, the AWS Config timeline is my favourite part of this tool. Each block shown on the timeline is a configuration item and the details of each change is captured. The example below shows the changes (rules) added to a Security Group. If the item chosen was a long-lived EC2 Instance, over the lifetime of the instance it would allow us to do some very interesting time travel through all the changes made. You can also view all of the Instances relationships to other AWS resources. Relationships are automatically generated for you and are bi-directional. Changes made to any resource are also automatically propagated to create Configuration Items for related resources. Note that data shown in the timeline view maybe up to 10 minutes old.
Config Rules
For building up the base capability of recording all changes, AWS have introduced AWS Config Rules. This allows you to define a value that Configuration Items should be set to in order to then alert and/or take action if that value is changed. There are two types of Config Rules that check the validity of configurations recorded:
- AWS Managed Rules – prebuilt and defined for you by AWS
- Customer Managed Rules – custom rules you build in AWS Lambda (supported languages – Java, JavaScript, Python). These execute in your account and requires you to maintain them
There are also two methods of triggering actions based on Config Rules. A rule can be raised when relevant resources change and these changes can be scoped to a specific resource ID, tag or group. To give you an example of this, if a resource is created that is tagged with PRODUCTION, the Configuration item will immediately be evaluated and / or an action will be triggered if the item does not meet the required criteria.
Secondly, you can create rules that are triggered periodically to ensure that a threshold of a number of instances is not exceeded within a 4 hour period. AWS use the concept of an Evaluation which is the result of evaluating a Config Rule against a resource. The Rules section clearly shows compliance or non-compliance with your defined rules.
A subtle thing to note is that if you define a rule for a tag that contains a number of Configuration Items and link it to a Config Rule, it will only be compliant if all items are compliant.
Some example Config Rules could be:
- All attached EBS (Elastic Block Storage) volumes must be encrypted
- All Security Groups in an attached state should not have unrestricted access to port 22
- All Security Groups in an attached state should not have unrestricted access to these defined ports
- All resources being monitored must be tagged with this tag – tag:value
- AWS CloudTrail must be enabled
Creating your own rules allows you to codify and automate your own internal practices. This means you can build in your own customised and bespoke guidelines for security and compliance. AWS Partners are also writing rules that can be run in Lambda.
In part three of this post, I will explore the growing ecosystem of partners around AWS Config, how the service can protect you from a common security concern and the reports that it can generate to solve security queries.
Avocado is a trusted partner of AWS with highly experienced consultants holding a wealth of knowledge in AWS applications. To talk to one of our Solution Managers in further detail, contact us today.
