AWS Reactive Governance

AWS Reactive Governance

 

Meaning of Tagging Governance for AWS Reactive Governance and Proactive:

In AWS, an efficient tagging strategy utilizes standardized tags then applies them continuously and programmatically across all the available resources. Both reactive and proactive approaches may be utilized for the sake of governing tags in the working AWS environment.

• When is AWS Reactive Governance needed?

AWS Reactive Governance is chosen for the sake of locating resources which were not properly tagged through utilizing tools like the AWS Config Rules, custom scripts or Resource Groups Tagging API. For the sake of finding resources manually, it is possible to utilize detailed billing reports or the Tag Editor.

• When is AWS Proactive Governance needed?

Proactive governance relies on tools like tag policies in AWS Organizations, the AWS Service Catalog, AWS CloudFormation, or IAM resource-level permissions for making sure that standardized tags are continuously being added upon resource creation.

This means that you are capable of utilizing the AWS CloudFormation Resource Tags property for the sake of adding tags to selected resource types. When using the AWS Service Catalog, you will be able to start adding portfolio and product tags which are added together and applied to a product directly upon its launching. Even better and stricter forms of proactive governance contain some automated tasks. For instance, you are capable of utilizing the Resource Groups Tagging API for the sake of searching an AWS environment’s tags, or running scripts to quarantine or delete resources that are not correctly tagged.

 

How to Perform AWS Reactive Governance with the AWS Config Rules?

It is possible to utilize already existing rules from AWS and from partners, and you are as well capable of setting your very own custom rules. Rules are capable of being targeted at particular resources according to id, particular types of resources, or at resources which are tagged in a specific manner. Rules start running as soon as these resources get created or altered, and they are capable as well of being evaluated periodically.

Rules are able to search whichever wanted or unwanted condition. For instance, you can:

• Make sure that EC2 instances which get launched in a specific VPC are effectively tagged.
• Ensure that each instance has a minimum of 1 security group.
• Go over to see to it that port 22 is not open in whichever production security group.

Every custom rule is merely an AWS Lambda function. The time that the function gets invoked for evaluating a resource, it gets associated with the Configuration Item of the resource. The function is capable of inspecting the item as well as perform calls to different AWS API functions needed. As soon as the Lambda function concludes its decision, it starts calling the PutEvaluations function for the sake of recording this decision and returning.

The rule invocations’ results get recorded and tracked on a per-resource basis. After that, they become available to the user from the AWS Management Console. They are also accessible in a report-oriented form, or through using the Config API.

 

Using an Existing Rule to Ensure AWS Reactive Governance:

To start utilizing one of the available rules included with Config, you simply head to the Config Console using the following link https://us-east-2.console.aws.amazon.com/config/home?region=us-east-2&awsc-custsat-override=promptUser#/welcome and click on Get Started.

Now, you’ll need to supply all the necessary information according to what suits you best, and then confirm setting up your AWS Config Rules.

After that, click on Rules from the navigation pane, then Add Rule:

Go through the available rules and choose which to start with. For example, select instances-in-vpc. It’s a rule for verifying that a specific EC2 instance belongs to a VPC, with an option for checking that it truly belongs to a particular VPC. Now, click on that rule and start customizing it as required:

Start by giving your rule a Name and a Description.

Choose for your Trigger: A Trigger Type, a Scope of changes and some Resources with an optional Resource identifier.

Now, for Rule parameters, give a Key and a Value.

By choosing a Trigger type you can tell Config to start running the rule either when the resource is changed, or periodically for specific periods. By choosing a Scope of changes, you can tell Config what your resources of interest are. You can set the scope according to resource type along with an optional identifier according to tag name, or according to a combination of tag name and tag value.

In case of checking EC2 instances, you will be able to trigger on one of the below options:

• Every single EC2 instance.
• Particular EC2 instances, defined by a resource identifier.
• Every resource which is tagged with the key “Department.”
• Every resource which is tagged with the key “Stage” as well as the value “Prod.”

Rule parameters will give you the ability to enter extra key and value pairs to a Lambda function. The names of the parameters, and the meaning of those parameters, are going to be specific to the selected function. Here, giving a value to the vpcid parameter will ask the function to start verifying that the EC2 instance runs within the set VPC.

The selected rule will be enabled as soon as you click on Save.

Go back to the Rules page, and check that your AWS configuration is set as noncompliant:

This problem can be handled through going over the Config timeline for the instance being examined:

You can finally conclude that this instance was not being used for a long time. This is how helpful using the Config Rules can be when aiming to reach AWS Reactive Governance!

In addition, the Config Console can be used for the sake of viewing the compliance status of every instances having a specific type:

How to Create a New Rule using Config for AWS Reactive Governance?

A new rule may be created with any language which is supported by Lambda.

The rule will get both the Configuration Item and the Rule Parameters mentioned above, and will implement whichever needed logic.

Here are some excerpts from a sample rule which is applied to EC2 instances, for checking if the rule was invoked on one of those instances:

function evaluateCompliance(configurationItem, ruleParameters) {

if (configurationItem.resourceType !== 'AWS::EC2::Instance') {

return 'NOT_APPLICABLE';

} else {

var securityGroups = configurationItem.configuration.securityGroups;

var expectedSecurityGroupId = ruleParameters.securityGroupId;

if (hasExpectedSecurityGroup(expectedSecurityGroupId, securityGroups)) {

return 'COMPLIANT';

} else {

return 'NON_COMPLIANT';

}

}

}

This code is in JavaScript.

In case the rule has been invoked on a specific EC2 instance, it will check to find if one of the list of expected security groups was attached to this instance:

function hasExpectedSecurityGroup(expectedSecurityGroupId, securityGroups) {

for (var i = 0; i < securityGroups.length; i++) {

var securityGroup = securityGroups[i];

if (securityGroup.groupId === expectedSecurityGroupId) {

return true;

}

}

return false;

}

This code is also in JavaScript.

At the end, the rule is going to store the result of this compliance check through calling the putEvaluations function of the Config API:

 

config.putEvaluations(putEvaluationsRequest, function (err, data) {

if (err) {

context.fail(err);

} else {

context.succeed(data);

}

});

This code is in JavaScript.

The rule is capable of recording results for the item under checking or whichever related item.

For example, if you are checking to ensure that an Elastic Load Balancer is attached just to a particular kind of EC2 instance. You can either choose to report compliance/noncompliance for this Elastic Load Balancer or the instance, according to what best suits your organization and your compliance model. This can be done for whichever resource type supported by Config.

Below you can see the way to create a rule for referencing your Lambda function:

First, you give it a specific Name and a Description to show what it’s for.

Then you give your Lambda ARN.

Select Change notification for Trigger Type.

Choose your Scope of changes to be Resource(s), and your Resources to be EC2 Instance.

Finally give a Parameter Key and Value according to what you need, and click on Save.

It couldn’t get any easier than this for assuring consistent AWS Reactive Governance in your organization.