How to make sure everyone in your team follows best practices when deploying AWS resources
If there are more than a couple of cloud engineers in your team how would you make sure everyone is adhering to best practices put forth by AWS and your enterprise? That’s where AWS policy evaluation mechanisms come into play. This article is intended to provide a theoretical overview of what are the different policy evaluation methods and different evaluation tools available for those methods.
Introduction
Policies mean a set of rules set by developers or cloud administrators which are defined based on cloud best practices and compliance requirements. Policy evaluation refers to checking whether a certain entity is adhering to those rules.
In this case, policies would be a set of valid configurations for AWS resources that must be followed according to the industry standards. For example, one of the most common AWS policies would be to only deploy databases inside private subnets without public access.
A policy evaluation tool would check configurations of databases in IaC templates or already deployed databases in the AWS account to make sure they are only associated with private subnets and identify any databases that are violating the above policy.
Now we have a better understanding of what policy evaluations are let’s jump into different policy evaluation methodologies.
Policy Evaluation Methodologies
There are two common policy evaluation methodologies when it comes to AWS which are proactive and detective evaluations.
Proactive policy evaluation is focused on preventing AWS resources that violate the policies being deployed. Proactive policy evaluators are employed before the AWS resource is provisioned. When using AWS CDK or CloudFormation these evaluators will test the JSON or YAML template against a set of policies that are predefined. Proactive evaluators provide options to stop the deployment altogether or just generate an event on the identification of non-compliant resources.
Detective policy evaluation is focused on assessing the already deployed resources against a set of policies. Detective policy evaluators will test the resource configurations to identify compliant and non-compliant resources and take remediation actions on them to make sure all resources follow the same standards. An alternative would be to generate a notification and make the required changes manually.
While proactive and detective are two different methodologies, they do not need to be mutually exclusive when it comes to designing the most cost-effective and secure environments.
Proactive Policy Evaluators
When it comes to AWS there are a couple of AWS-developed proactive policy evaluators.
AWS Config Proactive Evaluations
AWS Config is a managed service specifically designed for policy evaluations. It contains a lot of predefined rules that adhere to the best cloud practices. Config can evaluate policies in a strong detective mode and a weak proactive mode. While almost all predefined rules are supported in detective mode only a handful of them are supported in the proactive mode.
However, AWS Config does allow custom rules that can be used to enforce any kind of policy you want. The downside of this is that you have to write them from scratch using a programming language that AWS RDK or CDK supports or Guard domain-specific language.
AWS CloudFormation Guard is an open-source, general-purpose, policy-as-code evaluation tool. The Guard command line interface (CLI) provides a simple-to-use, yet powerful and expressive, declarative domain-specific language (DSL) that you can use to express policy as code.
AWS Config also supports integration with CloudFormation Hooks which are discussed below. This integration is useful for integrating AWS Config rules enforcement into CI/CD pipelines.
The following document in AWS documentation includes all the predefined rules that are supported in each evaluation mode.
Guard Validator Construct
If you are using AWS CDK as your choice of IaC, CfnGuardValidator can be a great choice. As the name suggests Guard validator evaluates the Cfn template a set of rules written in Guard domain-specific language.
By default, it evaluates the templates against all the rules set forth by the AWS Control Tower service. Developers have the choice to disable a couple of them via construct parameters. Another choice is to disable all Control Tower rules and implement a couple of hand-picked custom rules. You can write these custom rules from scratch in the Guard language or fetch ones already being used in AWS Config from aws-guard-rules-registry.
CloudFormation (Cfn) Hooks
CloudFormation hooks are designed to extend the capabilities of the CloudFormation service itself. They allow developers to run custom logic when a stack is being created, deleted, or updated. As we can return fail statuses in these custom logic that stop the deployment of the stack, we can use them to validate the templates against a specific set of rules.
The following document contains a great amount of details on developing and deploying these custom hooks. This guide describes initiating and developing hooks with CloudFormation CLI and related AWS libraries.
You also have alternatives to Cfn CLI and AWS libraries with open-source policy evaluators such as Open Policy Agent (OPA) as mentioned custom logic in CloudFormation hooks can contain anything. What matters is that you return success or fail status that will either continue or stop the resources provisioning respectively. The following guide provides a bootstrapping point for implementing CloudFormation hooks with OPA.
Detective Policy Evaluators
Detective policy evaluation focuses on evaluating the configuration of already provisioned resources. Detective evaluators can be triggered based on a schedule of configuration change events. A schedule is more suitable if you have a small set of resources that changes frequently. This can help in keeping the cost down. On the other hand, evaluating based on events can be great when you have a large amount of resources but the amount of small that happens over a period is small. You can combine these trigger types and form a hybrid strategy to optimize costs and fulfill your needs.
When it comes to AWS, you have a couple of choices for detective policy evaluators as well.
AWS Config
AWS config is a great tool for detective policy evaluations as you have a ton of options for implementing policies.
There are AWS-managed policies that conform to most of the cloud best practices. In most cases, these themselves are enough to ensure the security and compliance of your cloud infrastructure. These managed rules are written in Guard language and can be found in the AWS Config rules registry mentioned above.
If you have some custom policies in your enterprise which are not covered by AWS-provided policies you can implement them as custom policies or custom rules.
Custom policies are written in Guard language and are usually deployed with IaC providers. They do not incur any additional cost other than AWS rules evaluation cost.
Custom rules on the other hand are implemented as lambdas with the help of an IaC provider or using AWS Config Rules Development Kit (RDK). Custom rules incur lambda running costs in addition to AWS Config rule evaluation costs. However, they do provide the flexibility to use any custom logic or libraries such as OPA. The following guide describes how to develop and deploy these custom rules with the AWS RDK.
Once non-compliant resources are identified you can choose to remediate them automatically, terminate resources, or trigger a notification to alert the cloud team for manual remediation actions.
AWS Config provides a low code option to enforce policies in AWS in both proactive and detective evaluation modes. It also provides a host of other facilities such as resource inventories, built-in matrices, and a compliance status timeline for each resource.
Cloud Custodian (c7n)
Cloud Custodian is an open-source alternative to AWS Config. Cloud Custodian is designed for automating resource management in multiple cloud providers and its policies are defined in YAML.
Cloud Custodian rule evaluations can be triggered by CloudWatch events, CloudTrail events, and EC2 events or periodically with the in-built scheduler. Cloud custodian rules can be integrated with AWS Config and be deployed on AWS Lambdas for a serveries setup. Cloud custodian does not include a resource inventory and does not provide a configuration timeline.
While it provides much better flexibility for evaluations for little additional cost it requires manual setup and maintenance. However, it has the additional advantage of avoiding skill lock-in which is a common concern with Cloud computing. You can find official documentation for monitoring AWS resources with Cloud Custodian in the following link.
Conclusion
This article went over options for policy enforcement in AWS to ensure security and compliance in your enterprise architecture briefly. Policies can be evaluated in a proactive mode or a detective mode.
Proactive mode focuses on preventing the provisioning of non-compliant resources. CloudFormation hooks, Cfn Guard validator, and AWS Config proactive rules are a couple of the most widely used proactive evaluators.
Detective mode focuses on identifying policy violations in already deployed resource configurations. AWS Config is a great detective policy evaluator that provides great flexibility in defining rules and policies and provides a bunch of additional useful features such as resource inventory. Cloud Custodian is an open-source alternative to AWS config that requires manual setup and setting up rules from scratch but at a fraction of the cost.
