Automatically Remediate Noncompliant AWS Resources using Lambda
While enterprises are capable of rapidly scaling their infrastructure in the cloud, there’s a corresponding increase in the demand for scalable mechanisms to meet security and compliance requirements based on corporate policies, auditors, security teams, and others.
For example, we can easily and rapidly launch hundreds of resources – such as EC2 instances – in the cloud, but we also need to have approaches for managing the security and compliance of these resources along with the surrounding infrastructure. It’s not good enough to simply passively monitor noncompliant resources; you need to automatically fix the configuration that led to the noncompliant resources.
Using a collection of AWS services, you can detect non-compliant resources and automatically remediate these resources to maintain compliance without human intervention.
In this post, you’ll learn how to automatically remediate non-compliant AWS resources as code using AWS services such as AWS Config Rules, Amazon CloudWatch Event Rules, and AWS Lambda. You’ll learn the step-by-step instructions for configuring automated remediation using the AWS Console.
The diagram below shows the key AWS resources and relationships you’ll be creating.
Let’s get started!
Create an S3 Bucket for CloudTrail
In this section, you’ll create an Amazon S3 bucket for use with CloudTrail. If you’ve already established CloudTrail, this section is optional. Here are the steps:
- Go to the S3 console
- Click the Create bucket button
- Enter
ccoa-cloudtrail-ACCOUNTID
in the Bucket name field (replacingACCOUNTID
with your account id) - Click Next on the Configure Options screen
- Click Next on the Set Permissions screen
- Click Create bucket on the Review screen
Create a CloudTrail Trail
In this section, you’ll create a trail for AWS CloudTrail. If you’ve already established CloudTrail, this section is optional. Here are the steps:
- Go to the CloudTrail console
- Click the Create trail button
- Enter
ccoa-cloudtrail
in the Trail name field - Choose the checkbox next to Select all S3 buckets in your account in the Data events section
- Choose the No radio button for the Create a new S3 bucket field in the Storage location section.
- Choose the S3 bucket you just created from the S3 bucket dropdown.
- Click the Create button
Create an AWS Config Recorder
In this section, you’ll configure the settings for AWS Config which includes turning on the Conifig recorder along with a delivery channel. If you’ve already configured AWS Config, this section is optional. Here are the steps:
- Go to the AWS Config console
- If it’s your first time using Config, click the Get Started button
- Select the Include global resources (e.g., AWS IAM resources) checkbox
- In the Amazon SNS topic section, select the Stream configuration changes and notifications to an Amazon SNS topic. checkbox
- Choose the Create a topic radio button in the Amazon SNS topic section
- In the Amazon S3 bucket section, select the Create a bucket radio button
- In the AWS Config role section, select the Use an existing AWS Config service-linked role radio button
- Click the Next button
- Click the Skip button on the AWS Config rules page
- Click the Confirm button on the Review page
Create an S3 Bucket in Violation of Compliance Rules
In this section, you’ll create an S3 bucket that allows people to put files into the bucket. We’re doing this for demonstration purposes since you should not grant any kind of public access to your S3 bucket. Here are the steps:
- Go to the S3 console
- Click the Create bucket button
- Enter
ccoa-s3-write-violation-ACCOUNTID
in the Bucket name field (replacingACCOUNTID
with your account id) - Click Next on the Configure Options screen
- Unselect the Block all public access checkbox and click Next on the Set Permissions screen
- Click Create bucket on the Review screen
- Select the
ccoa-s3-write-violation-ACCOUNTID
bucket and choose the Permissions tab - Click on Bucket Policy and paste the contents from below into the Bucket policy editor text area (replace both
MYBUCKETNAME
values with theccoa-s3-write-violation-ACCOUNTID
bucket you just created) - Click the Save button
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": "*",
"Action": [
"s3:Abort*",
"s3:DeleteObject",
"s3:GetBucket*",
"s3:GetObject",
"s3:List*",
"s3:PutObject"
],
"Resource": [
"arn:aws:s3:::MYBUCKETNAME",
"arn:aws:s3:::MYBUCKETNAME/*"
]
}
]
}
You’ll receive this message: You have provided public access to this bucket. We highly recommend that you never grant any kind of public access to your S3 bucket.
Create an IAM Policy and Role for Lambda
In this section, you’ll create an IAM Policy and Role that established the permissions that the Lambda function will use. Here are the steps:
- Go to the IAM console
- Click on Policies
- Click Create policy
- Click the JSON tab
- Copy and replace the contents below into the JSON text area
- Click the Review policy button
- Enter
ccoa-s3-write-policy
in the *Name field - Click the Create policy button
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:DeleteBucketPolicy",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
],
"Resource": "*"
}
]
}
- Click on Roles
- Click the Create role button
- Click Lambda from the Choose the service that will use this role section
- Click the Next: Permissions button
- Click ccoa-s3-write-policy in the Filter policies search field
- Select the checkbox next to ccoa-s3-write-policy and click on the Next: Tags button
- Click the Next: Review button
- Enter
ccoa-s3-write-role
in the Role name field - Click the Create role button
Create a Lambda Function to Auto-remediate S3 Buckets
In this section, you’ll create a Lambda function that is written in Node.js and performs the automatic remediation by deleting the S3 Bucket Policy associated with the bucket. Here are the steps:
- Go to the Lambda console
- Click the Create function button
- Keep the Author from scratch radio button selected and enter
ccoa-s3-write-remediation
in the Function name field - Choose
Node.js 10.x
for the Runtime - Under Permissions choose the Choose or create an execution role
- Under Execution role, choose Use an existing role
- In the Existing role dropdown, choose
ccoa-s3-write-role
- Click the Create function button
- Scroll to the Function code section and within the
index.js
pane, copy and replace the code from below
var AWS = require('aws-sdk');
exports.handler = function(event) {
console.log("request:", JSON.stringify(event, undefined, 2));
var s3 = new AWS.S3({apiVersion: '2006-03-01'});
var resource = event['detail']['requestParameters']['evaluations'];
console.log("evaluations:", JSON.stringify(resource, null, 2));
for (var i = 0, len = resource.length; i < len; i++) {
if (resource[i]["complianceType"] == "NON_COMPLIANT")
{
console.log(resource[i]["complianceResourceId"]);
var params = {
Bucket: resource[i]["complianceResourceId"]
};
s3.deleteBucketPolicy(params, function(err, data) {
if (err) console.log(err, err.stack); // an error occurred
else console.log(data); // successful response
});
}
}
};
- Click the Save button
Create an AWS Config Rule
In this section, you’ll create an AWS Config Rule that uses a Managed Config Rule to detect when there are S3 buckets that allow public writes. The Managed Config Rule runs a Lambda function to detect when S3 buckets on not in compliance. Here are the steps:
- Go to the Config console
- Click Rules
- Click the Add rule button
- In the filter box, type
s3-bucket-public-write-prohibited
- Choose the s3-bucket-public-write-prohibited rule
- Click on the Remediation action dropdown within the Choose remediation action section
- Choose the AWS-PublishSNSNotification remediation in the dropdown
- Click Yes in the Auto remediation field
- In the Parameters field, enter
arn:aws:iam::ACCOUNTID:role/aws-service-role/ssm.amazonaws.com/AWSServiceRoleForAmazonSSM
in the AutomationAssumeRole field (replacingACCOUNTID
with your AWS account id) - In the Parameters field, enter
s3-bucket-public-write-prohibited violated
in the Message field - In the Parameters field, enter
arn:aws:sns:us-east-1:ACCOUNTID:ccoa-awsconfig-ACCOUNTID
in the TopicArn field (replacingACCOUNTID
with your AWS account id) - Click the Save button
Cloudwatch Event Rule
In this section, you’ll create an Amazon CloudWatch Event Rule which monitors when the S3_BUCKET_PUBLIC_WRITE_PROHIBITED Config Rule is deemed noncompliant. Here are the steps:
- Go to the CloudWatch console
- Click on Rules
- Click the Create rule button
- Choose Event pattern in the Event Source section
- In the Event Pattern Preview section, click Edit
- Copy the contents from below and replace in the Event pattern text area
- Click the Save button
- Click the Add target button
- Choose Lambda function
- Select the
ccoa-s3-write-remediation
function you’d previously created. - Click the Configure details button
- Enter
ccoa-s3-write-cwe
in the Name field - Click the Create rule button
{
"source":[
"aws.config"
],
"detail":{
"requestParameters":{
"evaluations":{
"complianceType":[
"NON_COMPLIANT"
]
}
},
"additionalEventData":{
"managedRuleIdentifier":[
"S3_BUCKET_PUBLIC_WRITE_PROHIBITED"
]
}
}
}
View Config Rules
In this section, you’ll verify that the Config Rule has been triggered and that the S3 bucket resource has been automatically remediated:
- Go to the Config console
- Click on Rules
- Select the s3-bucket-public-write-prohibited rule
- Click the Re-evaluate button
- Go back Rules in the Config console
- Go to the S3 console and choose the
ccoa-s3-write-violation-ACCOUNTID
bucket that the bucket policy has been removed. - Go back Rules in the Config console and confirm that the s3-bucket-public-write-prohibited rule is Compliant
Summary
In this post, you learned how to setup a robust automated compliance and remediation infrastructure for non-compliant AWS resources using services such as S3, AWS Config & Config Rules, Amazon CloudWatch Event Rules, AWS Lambda, IAM, and others. By leveraging this approach, your AWS infrastructure is capable of rapidly scaling resources while ensuring these resources are always in compliance without humans needing to manually intervene.
This general approach can be replicated for many other types of security and compliance checks using managed and custom config rules along with custom remediations. This way your compliance remains in lockstep with the rest of your AWS infrastructure.
Resources
- Remediate Non-Compliance Using AWS Config Rules, AWS CloudWatch Events, & AWS Lambda Functions – Screencast that goes through similar steps described in this post.
Stelligent Amazon Pollycast
|