Clear and Clean Policy As Code with Terraform and Terragrunt

There are times when security compliance and auditing make sense.  At times, there can be regulations and facilities requirements that exist that require that from a perspective indeed do qualify as security requirements and lead to the implementation of controls. Enter Policy As Code (PaC). 

The sole purpose of security is to enable the business to operate and succeed.  That may lead to, in fact, one or more frameworks, attestations, or governance requirements.

GRC, or Governance, Risk, and Compliance, allow an organization to keep an ecosystem of its security constructs together to action against.

One other concept I’d like to introduce is security policy.  The security policy is part of the organization that you action.  All of the above components can inform and influence your approach.   The construction and caretaking of the procedure may vary from organization to organization.   Security policies are essentially living documents that enable an organization to define the guidelines in which it operates.  

There is often a disconnect between these documents and the actual controls and processes along with those policies. 

Policy As Code is a concept that treats actual Code as a Policy or as a physical reference that can enact upon an organization’s assets.   Policy As Code means that you can build your environment out into source-controlled, peer-reviewed, testable, and releasable Code.  Policy As Code also means that changes to the policy are auditable through source control history.  Below is a sample of what a developer workflow might look like for updating Policy As Code.

policy as code

Several technologies can enable this to happen.  Terraform is a tool to manage anything with an Application Programmer Interface (API) consistently and accurately. Terraform layers a state machine on top of your desired configuration. There are many Terraform providers available (with the capability to write your provider). A provider is a unique library that communicates with the API to manage it.  

For example, let’s say you use AWS as your Infrastructure Cloud environment. You can write code to manage your infrastructure, also known as Infrastructure as Code. 

Infrastructure as Code means that you clearly and repeatedly define networks, platforms, security rules, alerts in code. Taking this concept, you can use Terraform to write policies and apply them constantly.  I posted a recent case where you could use Terraform to define a WAF rule for 0-days like Spring4Shell and Log4Shell Remote Code Execution Vulnerabilities.

Terraform can be extended to many parts of an organization to ensure that the policy requirements are communicated and actioned. 

Terraformed components could be, in addition to Infrastructure, Version Control, Networking, Expense Tracking, Collaboration, Employee Lifecycle, Communication, Data Warehousing, Container Orchestration, Continuous Integration/Continuous Deployment (CI/CD), Logging, Monitoring, and so on. It’s a limitless horizon in terms of what you can do. 

And again, if there is no provider, one can be authored.

There are other factors to consider. In some cases, you might be managing multiple tenants and need to enact the same Policy As Code baseline. Terraform structure requires careful planning, and I recommend using Terragrunt for this.  Terragrunt is a thin wrapper that allows for “Don’t Repeat Yourself” or DRY best practices for code. Using this approach, an organization can repeat its actions repeatedly on multiple tenants without having to maintain multiple codebases. Other tenants could include various environments, air-gapped, industrial control, and governmental classified networks.  

A function of compliance includes auditing or testing a policy and its controls. 

One of the ways software is tested with Behavior Driven Design. This approach entails writing tests first in plain text. There is a lot of great information about BDD out there, but the crux is that you convert written text to code that tests. Below is a sample test in English.

The testing logic can be applied to a Single-Sign-On Terraform provider to ensure a security control implementing said behavior occurs. There is a project called Terraform Compliance that attempts to do exactly this.  

Another helpful project that allows for this type of testing is Open Policy Agent (OPA). Open Policy Agent takes the same approach of testing your security controls. The Open Policy Agent has a vast ecosystem, including Terraform. 

There are so many more approaches to Policy As Code. The basic idea here is that you define your policy and its effect on your environment. It enables your organization to move in a fashion that keeps the policy as close as possible to changes happening.

Written By

We are in an active state of fighting invisible war whether we know it or not. This is what fuels me to want to help organizations understand their objectives and protect them

Related Posts