AWS Open Source Blog
Realize policy as code with AWS Cloud Development Kit through Open Policy Agent
AWS Cloud Development Kit (AWS CDK) is an open source software framework that allows users to define and provision AWS infrastructure using familiar programming languages. Using CDK, you can version control infrastructure, and the Infrastructure-as-Code concept opens up new opportunities to manage AWS infrastructure more efficiently and reliably.
But when planning to deploy new AWS resources or updating them, you must make sure these changes aren’t introducing vulnerabilities, or your organization might have baselines that you must follow per compliance requirements. And it’s time to set criteria to define operational readiness and keep security baselines to ensure that the infrastructure changes don’t cause problems. Open Policy Agent (OPA), a Cloud Native Computing Foundation incubating project, is designed to automate policy tests. OPA provides a unified framework and language for declaring, implementing, and controlling the policies of various components in cloud native solutions.
Integrated with AWS CDK, OPA can help you realize policy as code capability that tests the changes before AWS CDK makes changes in your AWS environment. This bring benefits in different ways, including:
- Individual team members could easily conduct check on changes.
- Policy evaluation can be automated through integration with CI/CD.
- Users can enforce preventative controls on the Infrastructure-as-Code input.
- Users can author custom OPA policies based on technical control requirements from industry best practice frameworks, such as CIS AWS Benchmark.
All in all, engineers will have a shortened feedback loop.
The rest of this post will walk through how to use OPA with AWS CDK for policy as code. Here is a list of high-level tasks that will be covered:
- Create an AWS CDK project to deploy AWS resources.
- Write a simple OPA policy based on REGO policy language.
- Leverage the OPA policy to validate the CDK infrastructure code.
Creating an EC2 environment in AWS Cloud9
Follow the instructions to create an Amazon Linux Cloud9 EC2 environment as the workspace, and you can use the Cloud9 environment for the rest of the post.
Ensure AWS CDK is installed
Create an AWS CDK project
The CDK project will create an AWS CloudFormation stack of an Amazon Elastic Compute Cloud (Amazon EC2) instance, an AWS Identity and Access Management (IAM) role, a security group attached to the EC2, etc.
Apply project template app for Python
Install the virtualenv
Enter the virtualenv
Install all required packages
Edit the AWS CDK project to create resources
Create AWS CloudFormation template
The template will be generated as
cdk.out/cdk-demo.template.json. If we run
cdk deploy now, the CloudFormation stack will be launched and all the resources declared will be created. Before applying the changes, however, let us do validation with OPA to ensure there are no violations on security or operation policies.
Write OPA policy in Rego
The policies in this example will check the AWS CloudFormation template on three aspects:
- Whether it creates more than 10 EC2 instances
- Whether SSH is enabled on EC2 instance
- Whether an IAM role is created
Evaluate the OPA policy
Run OPA policy against the AWS CloudFormation template:
The output shows that the CloudFormation template does pass the check for the number of EC2 instances to be created, but violates the policies of not creating IAM role and not enabling SSH on an EC2 instance.
The deploy shouldn’t be conducted until the template passes all the policy tests. OPA helps to ensure only policy-passed infrastructure changes will go to production.
Delete the Cloud9 EC2 environment from the AWS Console.
The example above is a hello world demonstration that shows a way of using OPA to validate and determine whether a proposed AWS CDK update is authorized. I think this example can be applied to other use cases as well, such as ensuring all resources have tags before they are created, making sure naming standards for resources are followed, meeting security or operational requirements, and so on.
Knowing early whether an application or infrastructure deployment is in violation of policy definitions is useful. Thus, this policy evaluation should be a step in the workflows of an infrastructure lifecycle and to fail deployments that create non-compliant resources.
OPA can run as a daemon side-by-side with your service and provide RESTful APIs using JSON over HTTP. For services written with Go, OPA can instead be embedded and used as a library. Using OPA with AWS CDK highly extends on Infrastructure-as-Code, which provides self-service capability and end-to-end automation for infrastructure policy testing.
This blog post provided an example use case that you can apply in your context, in your organization. There are dozens of other policies you will want to enforce in your environment for security, cost, and availability reasons. You could start with your own requirements for access control and for putting constraints on containerized workloads, and you can use OPA with the AWS CDK to build policy-driven infrastructure, to enforce constraints, to provide guardrails, and to govern cloud resources with confidence.
Now you are one step closer to DevSecOps—you could integrate OPA with your CDK, AWS CloudFormation, or a Terraform-backed Infrastructure-as-Code pipeline, and make use of the OPA output to automatically fail or pass a deployment. With the power of these open source tools, the possibilities are almost endless.
Feature image via Pixabay.