How to secure your cloud with AWS Config

AWS Config is a service that enables you to assess, audit, and evaluate the configurations of your AWS resources. This can be used for:

security: validate security best practices on your AWS Account
compliance: report on deviations on configuration for AWS resources based upon best practices or architectural principles and guidelines
efficiency: report on lost or unused resources in your AWS Account

In this blog post, I’d like to detail how to monitor your cloud resources with this tool. This first part discusses AWS Config account setup, enabling notifications when resources are not compliant, and deployment.

Why use AWS Config?

AWS is the main cloud platform we use at ACA. We manage multiple accounts in AWS to host all sorts of applications for ourselves and for our customers. Over the years, we set up more and more projects in AWS. This led to a lot of accounts being created, which in turn use a lot of cloud resources. Naturally, this means that keeping track of all these resources becomes increasingly challenging as well.

AWS Config helped us deal with this challenge. We use it to inventorize and monitor all the resources in our entire AWS organization. It also allows us to set compliance rules for our resources that need to be conform in every account. For example: an Elastic IP should not be left unused or an EC2 security group should not allow all incoming traffic without restrictions. This way, we’re able to create a standard for all our AWS accounts.

Having AWS Config enabled in your organization gives us a couple of advantages.

We always have an up-to-date inventory of all the resources in our accounts.
It allows to inspect the change history of all our resources 24/7.
It gives us the possibility to create organization rules and continuously check if our resources are compliant. If that’s not the case, we instantly get a notification.

Setting up AWS Config for a single account

In this first part of my AWS Config blog, I want to show how to set up AWS Config in a single account. In a future blog post, I’ll explain more about you can do this for an entire AWS organization. The image below shows an overview of the setup in a single account, containing

the AWS Config recorder,
the AWS Config rules,
and the S3 bucket.

AWS congif recorder explained with a figure

The AWS Config recorder is the main component of the set-up. You can turn on the default recorder in the AWS console. By default, it will record all resource types. You can find more information about all the available resource types on this page.

AWS config settings overview

When you start recording, all the the AWS resources are stored in the S3 bucket as configuration items. Recording these configuration items is not free. At the point of writing it costs $0.003 per recorded configuration item. This cost is generated when the configuration item is first recorded or when something changes to it or one of its relationships. In the settings of the AWS Config recorder, you can also specify how long these configuration items should be stored in the S3 bucket.

The AWS Config rules are the most important part of your setup. These rules can be used as compliancy checks to make sure the resources in your account are configured as intended. It’s possible to create custom rules or choose from a large set of AWS managed rules. In our setup at ACA, we chose to only use AWS managed rules since they fitted all our needs. In the image below, you can see one of the rules we deployed.

AWS config settings rules

Just like recording configuration items, running rule evaluations costs money. At the moment of writing this is $0.001 for the first 100.000 rule evaluations per region, $.0008 from 100.000 – 500.000 and after that $.0005.

There are a lot of rules available with different benefits to your AWS account. These are some of the AWS managed rules we configured:

Rules that improve security
- AccessKeysRotated: checks if the Access keys of an IAM user are rotated within a specified amount of days
- IamRootAccessKeyCheck: checks if a root account has access keys assigned to it, which isn’t recommended
- S3BucketServerSideEncryptionEnabled: checks if default encryption for a S3 bucket is enabled
Rules that detect unused resources (cost reduction)
- Ec2VolumeInuseCheck: checks if an EBS volume is being used
- EipAttached: checks if an Elastic IP is being used
Rules that detect resource optimizations
- VpcVpn2TunnelsUp: checks if a VPN connection has two tunnels available

Setting up notifications when resources are not compliant

AWS Config rules check configuration items. If a configuration item doesn’t pass the rule requirements, it is marked as ‘non compliant’. Whenever this happens, you want to be notified so you can take the appropriate actions to fix it. In the image below, you can see the way we implemented the notifications for our AWS Config rules.

notifications implemented in AWS config rules

To start with notifications, CloudTrail should be enabled and there should be a trail that logs all activity in the account. Now CloudWatch is able to pick up the CloudTrail events. In our setup, we created 5 CloudWatch event rules that send notifications according to priority. This makes it possible for us to decide what the priority level of the alert for each AWS Config rule should be. The image below shows an example of this.

AWS config rule explained how to create rule

In the ‘Targets’ section, you can see the SNS topic which receives the messages of the CloudWatch event rule. Opsgenie has a separate subscription for each of the SNS topics (P1, P2, P3, P4 & P5). This way, we receive notifications when compliance changes happen and also see the severity by looking at the priority level from our Opsgenie alert.

OpsGenie SNS topic

Deploying your AWS Config

At ACA, we try to always manage our AWS infrastructure with Terraform. This is no different for AWS Config. This is our deployment workflow:

deployment workflow terraform

We manage everything AWS Config related in Terraform. Here’s an example of one of the AWS Config rules in Terraform, in which the rule_identifier attribute value can be found in the documentation of the AWS Config managed rules:

resource "aws_config_config_rule" "mfa_enabled_for_iam_console_access" {
  name                        = "MfaEnabledForIamConsoleAccess"
  description                 = "Checks whether AWS Multi-Factor Authentication (MFA) is enabled for all AWS Identity and Access Management (IAM) users that use a console password. The rule is compliant if MFA is enabled."
  rule_identifier             = "MFA_ENABLED_FOR_IAM_CONSOLE_ACCESS"
  maximum_execution_frequency = "One_Hour"
  excluded_accounts           = "${var.aws_config_organization_rules_excluded_accounts}"
}

The Terraform code is version controlled with Git. When the code needs to be deployed, Jenkins does a checkout of the Git repository and deploys it to AWS with Terraform.

Takeaway

With AWS Config we’re able to get more insights in our AWS cloud resources. AWS Config improves our security, avoids keeping resources around that are not being used and makes sure our resources are being configured in an optimal way. Besides these advantages, it also provides us with an inventory of all our resources and their configuration history, which we can inspect at any time.

This concludes this blog post on the AWS Config topic. In a future part I want to explain how to set it up for an AWS organization. If you found this topic interesting and you got a question or if you would like to know more about our AWS Config setup, then please reach out to us at cloud@aca-it.be.

I want to automatically secure my cloud