How do you keep track of changes to your AWS Cloud based solutions? In our latest AWS Cloud Foundations post, we look at configuration management. Specifically, we will focus on AWS Config, a service that allows you to continuously monitor the configurations of AWS resources and be notified off changes.

Configuration Management?

Configuration Management manages the identification, recording, and reporting of IT infrastructure components, including their versions, constituent components and relationships

Why are we talking about Configuration Management? Quite simply, nnowing the configuration of your AWS services is critical to protecting your AWS environment. Most importantly, you want to know about any risky changes or any changes that may breach your security policy.

AWS Config provided that capability and is super easy to setup!

What is AWS Config?

AWS Config provides you a simple way to have a single view of your AWS resource, including cross-account for multi-account solutions. You can even add third party or custom resources to AWS Config. With Config you can

  • Gain visibility of your resources. This includes using Config as a discovery tool for all the AWS resources in you account(s)!
  • Identify changes to resources, including a change history. This included relationships between resources;
  • Measure your compliance to your security policy or to external standards such as PCI DSS using managed configuration packs;
  • Be notified of changes to resources for security alerting and potential remediation. Config uses rules (both managed and custom) to check resources against a desired. configuration. There are currently 127 AWS Managed Rules.

Getting started

It’s very simple to get started. First, go to the Config console and click on Get started.

In the settings page, make sure you enable global resources and setup a bucket for storing details of configuration changes. If you want configuration management changes delivered to you, you can enable streaming through SNS. Note that this will create a fair volume of notifications in your environment that you may want to filter. In general we just pickup logs from S3 and filter the events.

Click on Next and skip the rules setup. We will do this later. Click on Next and then Save to setup Config.

Config will now go and discover your resources. Depending on how many resources you have, this may take a little while. Once resources (also known as configuration items) appear you can filter resources and click on one to see the details. The details page includes a timeline of changes applied to the resource.

If you want to see resources across all your accounts, you need to setup an aggregator in one of your accounts and then add the accounts or the AWS Organization to monitor. For multi-account setups, we definitely recommend doing that and then applying baseline rules (see below) commonly across all your accounts. To do so, you delegate an account in your Organization as the Config administrator.

Config also provides a SQL like query language under Advanced queries. There are a number of pre-canned queries or you can create your own.

Enabling rules

Once we have resources in the inventory, we need to setup some rules to manage the configuration.

The simplest way to enable Config rules is to use a Conformance Pack. Conformance Packs are a collection of AWS Config rules. By selecting a pack, you will enable a bunch of rules. Note that the Config service is priced based on running of rules (as well as the number of configuration items). If you enable a number of rules, there is no cost until the rule is evaluated.

Whenever a resource that is related to the rule is created, modified or deleted, the rule is evaluated against that resource. You can even scope the resources that trigger a rule evaluation using tags. You can also trigger the rule manually or on a schedule

One of the most common set of rules to enable is for the AWS PCI Benchmark v1.3 level 2. Note that if you enable multiple conformance packs, you may well double up on rules. Some rules, such as the foundational check that CloudTrail is enabled, are included in multiple packs. In this case, you should remove the rule from one of the packs. The rule sets that make sense for your environment will depend on your organisation’s compliance requirements.

You can also create custom rules. Custom rules use a Lambda function to run the evaluation logic.

Alerting & remediation

One of the great features of Config for compliance management is the ability to be notified of changes and non-compliant rules. These are posted to the S3 bucket (and optionally to the SNS topic) that we configured earlier. You can also see the compliance status against a rule or a resource in the Config console.

You can use these notifications to trigger other actions.

  • With S3 logs, you can ingest them into your monitoring solution, such as Sumologic from where you can create dashboards and alerts;
  • You can send SNS notifications to email or send them to Lambda to perform some action.

What about remediating the configuration? You can actually enable remediation actions within Config!

If you click into a rule, you can see in the top right the ability to Manage remediation. Behind the scenes, the remediation uses Systems Manager automation documents. You can use the standard AWS managed automation or build your own in Systems Manager. These documents define the actions to perform. You can configure the automation to run automatically or manually.

Setting up remediation

Let’s run through an example for the rule that checks that S3 bucket versioning is enabled, s3-bucket-versioning-enabled.

  • Enable the rule s3-bucket-versioning-enabled;
  • Click on this rule;
  • Select Manage remediation;
  • For now, select Manual remediation and in the remediation action select the remediation action AWS-ConfigureS3BucketVersioning;
  • Under the Resource ID parameter, select the BucketName. The list of parameters available will vary with each action;
  • Click on Save changes.

Testing remediation

Let’s see if the remediation works!

First off we create a new bucket. Being the good citizen we are, we enabled encryption for the bucket. However, we didn’t turn on bucket versioning which is a breach of our security policy.

As earlier, we have set up a rule with remediation for this exact scenario! We wait a few minutes and the resource appears in Config and is evaluated against the rule. As we expect it comes up non-compliant. We click into the rule s3-bucket-versioning-enabled and we can see the bucket in the list of resources. Selecting the bucket, we click on Remediate. Within seconds, it comes back with Action executed successfully! After a little while, the resource will be marked as compliant.

If we go back to the bucket, we can see that versioning is now enabled.

Of course, when we are ready we can enable this remediation to happen automatically. In that case, we can setup Config so that we are notified that the remediation has happened but without any manual input required!

Wrapping Up

For configuration management, AWS Config has your back. We didn’t discuss in detail compliance and auditing of your environments. AWS Systems Manager can be used to provide this capability. You can also hook Config into AWS Security Hub (which we will cover in a future blog post) for a single view of your compliance to configuration.

If you would like to dive deeper into configuration management in AWS, please get in contact with us at RedBear. Look out for our next instalment in our AWS Security Foundations series next week!

Close Menu