Policy as Code with OPA and Terraform on Cloudy Mountains

Allow Only Approved AMIs in Terraform with OPA

Mon, 23 Jun 2025 13:00:44 +0100

In the part 2, we provided examples of how you can enforce AWS tags to ensure compliance and governance within your organization. In this post, we will extend those concepts by demonstrating how you can enforce specific AMI IDs using OPA policies, helping you maintain control over the AMI images used in your infrastructure.

It is critical for all organizations to establish a robust AMI building process to ensure that operating systems are consistently patched for security vulnerabilities. By maintaining control over the AMI lifecycle, organizations can enforce compliance, reduce exposure to risks, and ensure that their infrastructure remains secure and up-to-date. This process not only helps in mitigating potential threats but also aligns with best practices for infrastructure management and governance. This process is typically managed by the Security team, who are responsible for building and maintaining approved AMIs. The “customers” of these AMIs are other teams within the organization, such as Development, Operations, or QA, who rely on these pre-approved images to ensure their workloads meet security and compliance standards.

Enforcing AWS Resource Tags with OPA

Fri, 13 Jun 2025 13:00:44 +0100

In Part 1 of this series, we covered the basics of Policy as Code and how the shift-left approach helps catch infrastructure mistakes early. In this post, we’re putting theory into practice—specifically, how to enforce AWS tagging strategy using Open Policy Agent (OPA) during Terraform plan phase/stage.

This isn’t just about tagging hygiene. Good tagging is foundational for tracking cloud costs, understanding ownership, and avoiding dangerous or expensive mistakes.

Why Tags Matter

Tags seem trivial—until you’re staring at a $1M AWS bill and have no idea where it came from.

Testing Terraform Plans with OPA and Conftest (and Atlantis)

Thu, 15 May 2025 23:58:44 +0100

As I mentioned in my previous blog post, my first OPA policy was just to catch one simple parameter, if we have in the S3 Terrafom module set the force_destroy = true.

Here’s a simple OPA policy that will catch this dangerous configuration:

package terraform.plan

deny[msg] {
 # Find all resources in the plan
 resource := input.resource_changes[_]
 
 # Check if it's an S3 bucket
 resource.type == "aws_s3_bucket"
 
 # Look for force_destroy in the configuration
 resource.change.after.force_destroy == true
 
 msg := sprintf("S3 bucket '%s' has force_destroy set to true. This is dangerous as it allows bucket deletion even when not empty.", [resource.address])
}

This policy works by:

How I Learned the Hard Way That Terraform Needs Policy as Code

Sun, 30 Mar 2025 13:00:44 +0100

At a glance

Context: a cloud consultancy engagement, bootstrapping 15 new AWS accounts for a client with Terraform 0.11/0.12.
Incident: I accidentally deleted the S3 bucket that held the Terraform state for all 15 accounts.
Cost: all 15 accounts were recreated and provisioned again from scratch. Because everything was code, that took less than two days. The real cost was our reputation with the client.
Fix: policy as code. OPA policies evaluated against every terraform plan in CI, failing the pipeline before a dangerous change reaches apply.
Outcome: 15 workload pipelines gated, and every pipeline created after them inherited the same checks.

What went wrong?

A few years ago, while working for a cloud consultancy company, I made a mistake that I will never forget. I accidentally deleted a Terraform state bucket: the S3 bucket that stored the state for bootstrapping 15 AWS accounts, each packed with resources. To make things worse, it belonged to a very tough client.

Shift-Left Cost Checks for Terraform with OPA and Terracost

Fri, 31 May 2024 13:00:44 +0100

Introduction

In the fast-evolving world of cloud computing, managing costs effectively has become a crucial aspect of maintaining a sustainable and profitable business. The “Shift left” paradigm, originally a concept in software development, emphasizes the importance of addressing potential issues early in the development process. When applied to AWS cost optimization and management, this approach ensures that cost considerations are integrated into the earliest stages of the development lifecycle.

By shifting cost management left, organizations can avoid unexpected expenses and optimize their cloud spending proactively. This blog post explores the application of the “Shift left” paradigm to AWS cost optimization, focusing on tools like Open Policy Agent (OPA) policies, Infracost, and Terracost. We will delve into how these tools can help estimate and control costs efficiently, ensuring that your AWS resources are both cost-effective and aligned with your financial goals.