Adam is a backend software engineer at Spacelift. He has a background in full-stack web development, infrastructure automation, and deploying applications to Azure.

All posts by Adam Connelly - Infrastructure as Code Expert

Adam Connelly

Guide to Balancing Speed and Control in DevOps

Product

Why Spacelift

How it Works

Spacelift platform

Terraform

Ansible

OpenTofu

See all integrations

Integrations

vs Terraform Cloud

vs Terraform Enterprise

vs Atlantis

vs Generic CI/CD

Compare

Register now

introducing-saturnhead-ai-blog-image

Introducing Saturnhead AI Blog Image

Introducing Saturnhead AI

Solutions

Scale your infrastructure safely and efficiently with an end-to-end workflow

productivity

Productivity

productivity-2

IaC at Scale

Standardize and control infrastructure provisioning and configuration

cicd

CICD

cicd-2

Infrastructure Governance

Implement and automate secure, collaborative workflows

team

Team

team-2

Collaboration

Make it easy for developers to provision and configure with a single workflow

speed-2

Speed

speed-3

Developer Velocity

By Initiative

CI/CD for Infrastructure

Drift Detection

Achieve Terraform at Scale

OpenTofu Migration

By Use Case

Request a meeting

Enjoy an action-packed day at AWS Summit London 2024, where the latest in cloud innovation comes to life.

ebook-pic

Practitioner’s Guide to Scaling IaC

Check out the Practitioner's Guide to Scaling IaC

Docs

Pricing

Resources

Learn more about Spacelift and infrastructure best practices

blog

Blog

blog-2

partners

Partners

partners-2

events

Events

events-2

eBooks, webinars, cheat sheets and tools to get you started

cheatsheets

Cheatsheets

cheatsheets-3

Resource Library

users

Users

users-2

Case Studies

Essential content and resources to help you achieve IaC excellence

chat-3

media guide

chat-hover

media guide hover

Mission Guides

539-infra-automation-report-1

539.infra automation report

The Infrastructure Automation Report, 2025

About Us

Contact Us

Accessibility

About

cheatsheets-2

Test

See more

Test webinar name

You focus on building. We’ll keep you updated. Get curated infrastructure insights that help you make smarter decisions.

AWS re:Invent Revisited: 2023 Highlights

YAML Tutorial : A Complete Language Guide with Examples

How to Restart Kubernetes Pods With Kubectl

Ansible Tutorial for Beginners: Ultimate Playbook & Examples

Terraform .tfvars files: Variables Management with Examples

How to Stop and Remove Docker Containers

Terraform Map Variable - What It is & How to Use

Kubernetes Deployment YAML File with Examples

Kubectl cp - How to Copy File From Pod to Local (5 Examples)

How to Use Terraform Variables: Examples & Best Practices

Kubectl Cheat Sheet - 15 Kubernetes Commands & Objects

Importing Existing Infrastructure Into Terraform - Step by Step

20 Best AI-Powered Coding Assistant Tools in 2025

How to Expose a Docker Port - Tutorial & Examples

How to View Kubernetes Pod Logs Files With Kubectl

AWS S3 Cp [Copy] Command Overview with Examples

How to Add Comments in a YAML File [Tutorial]

Top 12 Most Useful Docker Alternatives for 2025 [List]

Kubernetes Ingress with NGINX Ingress Controller Example

Terraform Tutorial - Getting Started With Terraform

Docker Volumes - Guide with Examples

Terraform For Loop - Expression Overview with Examples

What Are Terraform Modules and How to Use Them: Tutorial

Top 27 Software Development Tools & Platforms [2025 List]

How to Use Ignore_Changes in Terraform Lifecycle

How to Use Kubectl Delete Deployment in Kubernetes: Examples & Tricks

Want to level up your Terraform knowledge? Explore our tutorials and step-by-step guides written by Terraform experts. Learn Terraform best practices and solutions to the most difficult problems.

Terraform Guides and Tutorials | Spacelift Blog

<dfn>Open Policy Agent</dfn> is an open-source engine that provides a way of declaratively writing policies as code and then using those policies as part of a decision-making process. It uses a policy language called Rego, allowing you to write policies for different services using the same language.
In this article, I will give an overview of OPA, explain why you should use it, and showcase how you can use it with your Spacelift account. Although OPA can serve many purposes, I’m going to focus on how it can be used alongside <a href="https://spacelift.io/blog/infrastructure-as-code" target="_blank" rel="noopener">infrastructure as code</a>.

Open Policy Agent (OPA) is a general-purpose policy engine that enables unified, context-aware policy enforcement across diverse systems. It lets developers define policies using a high-level declarative language called Rego and evaluate those policies over structured data.
OPA allows policies to be written and maintained separately from application logic, enabling consistent enforcement across APIs, microservices, Kubernetes, CI/CD pipelines, and infrastructure components. It operates by receiving JSON data as input and returning decisions based on the defined rules.
OPA can be used for a number of purposes, including:
<ul>
<li style="font-weight: 400;" aria-level="1">Authorization of REST API endpoints</li>
<li style="font-weight: 400;" aria-level="1">Allowing or denying Terraform changes based on compliance or safety rules</li>
<li style="font-weight: 400;" aria-level="1">Integrating custom authorization logic into applications</li>
<li style="font-weight: 400;" aria-level="1">Implementing Kubernetes Admission Controllers to validate API requests</li>
</ul>
OPA was originally created by Styra and is now part of the Cloud Native Computing Foundation (CNCF), alongside other CNCF technologies like Kubernetes and Prometheus.

OPA accepts a policy, input, and query and generates a response based on that. The input can be any valid JSON document, allowing OPA to integrate with any tool that produces JSON output.

We can visualize how OPA works using the following diagram:

how-does-opa-work

Open Policy Agent (OPA) Example

In the following sections, I’ll go into more specific examples of using OPA that should help make things clearer but before I do, here’s a quick list of reasons why I’m interested in using OPA:
<ul>
<li style="font-weight: 400;" aria-level="1">Policies as code allow you to follow your standard development lifecycle with PRs, CI, etc., and provide you with a history of changes to your policies.</li>
<li style="font-weight: 400;" aria-level="1">OPA is designed to work with any kind of JSON input, meaning it can easily integrate with any tool that produces JSON output.</li>
<li style="font-weight: 400;" aria-level="1">Because OPA integrates with a number of different tools, it allows you to use a standard policy language across many parts of your system, rather than relying on multiple vendor-specific technologies.</li>
<li style="font-weight: 400;" aria-level="1">OPA supports unit-testing, making it easier and faster to iterate your policies with confidence that they won’t break.</li>
</ul>

Let’s try to make that a bit less theoretical by using a specific example: Terraform. Terraform can produce a plan in JSON format via the terraform show command. This means that we can define policies for our infrastructure, and use OPA to make a decision about whether a plan is safe to apply or not:

using-opa-with-terraform

using opa with terraform

For example, say we have the following Terraform definition to create an EC2 instance:

Now, say we want to ensure that every Terraform resource has a Name tag. We could enforce that by creating a file called plan.rego with the following content:

In order to use OPA to evaluate our policy, we need to take the following steps:
<ol>
<li>Generate a Terraform plan as JSON.</li>
<li>Run opa eval to verify whether that plan passes our policy or not.</li>
</ol>

<h3>Step 1 &#8211; Generate our Terraform plan as JSON</h3>
To get a JSON representation of our plan, we need to output our plan to a file, and then use the terraform show command to output that plan as JSON:

<h3>Step 2 &#8211; Run opa eval</h3>
We can then use opa eval to evaluate our plan against our policy:

As you can see, we’re using the query data.spacelift.allow because our policy is loaded as a data file, and we defined our allow rule in the spacelift namespace. You can also see that opa eval produced an empty output ({}). This means that our allow rule didn’t evaluate to true, and so produced no output.
Let’s adjust our Terraform definition to include a Name tag:

Now if we generate our plan and evaluate the policy again, we should get a slightly different output:

This tells us that the allow rule has evaluated true. We can get that in a slightly more concise way by using the pretty format option:

At this stage, you can probably imagine how you could integrate this into your <a href="https://spacelift.io/blog/terraform-in-ci-cd" target="_blank" rel="noopener">CI/CD pipeline </a>to enforce naming schemes, security rules, and various other organizational policies.
Note: New versions of Terraform are be placed under the BUSL license, but everything created before version 1.5.x stays open-source. <a href="https://opentofu.org/" target="_blank" rel="nofollow noopener">OpenTofu</a> is an open-source version of Terraform that expands on Terraform’s existing concepts and offerings. It is a viable alternative to HashiCorp’s Terraform, being forked from Terraform version 1.5.6.

<ul>
<li><a href="https://spacelift.io/blog/how-specialized-solution-can-improve-your-iac" target="_blank" rel="noopener">11 Ways to Improve Your Infrastructure Orchestration</a></li>
<li><a href="https://spacelift.io/blog/infrastructure-problems-that-spacelift-solves" target="_blank" rel="noopener"><span data-sheets-value="{&quot;1&quot;:2,&quot;2&quot;:&quot;Common Infrastructure Challenges and How to Solve Them&quot;}" data-sheets-userformat="{&quot;2&quot;:513,&quot;3&quot;:{&quot;1&quot;:0},&quot;12&quot;:0}">Common Infrastructure Challenges and How to Solve Them</a></li>
<li><a href="https://spacelift.io/blog/ci-cd-tools" target="_blank" rel="noopener">Top Most Useful CI/CD Tools for DevOps</a></li>
</ul>

The following examples illustrate some possible use-cases for <a href="https://spacelift.io/blog/open-policy-agent-opa-terraform" target="_blank" rel="noopener">OPA with Terraform</a>. All of the examples have been taken from the Spacelift <a href="https://docs.spacelift.io/concepts/policy/terraform-plan-policy#cookbook" target="_blank" rel="noopener">plan policy documentation</a>, but have been altered to work with plain vanilla Terraform.
<h3>Example 1. Require human review when resources are deleted or updated</h3>
Adding new resources is usually a fairly safe operation, but updating or deleting existing resources can carry more risk. You could flag these for human review by using the following policy:

<h3>Example 2. Require commits to be reasonably sized</h3>
Once a PR exceeds a certain size it becomes difficult to review without missing things. The same is true for Terraform plans. The following policy can be used to warn when the number of changes goes over a certain threshold:

<h3>Example 3. Blast radius</h3>
The following policy attempts to determine the risk of a particular plan by assigning different weightings to the change type (create, update, delete), along with the affected resource type (ECS cluster, EC2 instance, etc.). It takes the approach that an update or delete is more risky than a create because it affects an existing resource:

How can we make sure that our policies work as expected and don’t break over time as we make changes to them? You guessed it: unit testing! Luckily for us, OPA has first-class support for testing via the opa <code>test</code> command.
To create tests for our policy, all we need to do is create another Rego file with a series of rules prefixed with <code>test_</code>. Each rule starting with that prefix defines a separate test. 
Let&#8217;s go ahead and create a file called plan_test.rego, with the following contents:

As you can see, OPA makes it really easy to specify the policy input using the <code>&lt;variable&gt;</code> as <code>&lt;value&gt;</code> syntax. This allows us to create very concise tests by only including values we care about in the policy input, rather than having to use the entire plan output.
Let&#8217;s go ahead and run <code>opa test</code>:

Unsurprisingly our test passes. That&#8217;s not very exciting, so let&#8217;s add a new test to ensure our resources include an <code>Environment</code> tag:

Running opa test again shows us a failure:

We can fix this by updating our policy:

At this stage if you run the test command again it should show 2 passes:

If you want to know more about OPA testing, the <a href="https://www.openpolicyagent.org/docs/latest/policy-testing/" target="_blank" rel="nofollow noopener">official docs</a> are full of great examples and information about what you can do.
Read more about writing policies in Rego: <a href="https://spacelift.io/blog/open-policy-agent-rego" target="_blank" rel="noopener">OPA Rego Examples &amp; Tutorial (Introduction to Open Policy Agent Rego Language) </a>

At this stage, you should have a pretty good idea of what OPA is and how it can be useful to you. It’s not too difficult to see how you could start integrating OPA into your development process or even use it as part of production systems.
Luckily for you, at Spacelift, we’ve done all the heavy lifting, allowing you to reap the benefits of using OPA for policy as code without having to implement everything from scratch yourself. In this section, I want to showcase some of the functionality that Spacelift provides as it relates to OPA.
Check out this video where we dive into common use cases of Spacelift policies and how teams are using them to achieve security and cost control of their infrastructure:

policy-as-code-for-secure-resilient-infrastructure-youtube

Policy-as-code for Secure, Resilient Infrastructure - YouTube

<h3>1) Policy types</h3>
Spacelift allows you to use <a href="https://resources.sei.cmu.edu/asset_files/Presentation/2021_017_001_739363.pdf" target="_blank" rel="noopener">OPA policies</a> to manage various aspects of your Spacelift account, and not just during planning. For example, you can use policies to control who can log into your account, along with what they have access to. For more information, see <a href="https://docs.spacelift.io/concepts/policy/" target="_blank" rel="noopener">Policy as Code</a>.
<h3>2) PR checks</h3>
Spacelift can automatically trigger planning runs whenever you push changes to your VCS provider. For example, here’s what you might see in after creating a PR:

spacelift-opa-pr-checks

spacelift opa pr checks

If all goes well, your check will succeed, but if a policy is violated, a failed check will be reported. In our case, everything went smoothly:

open-policy-agent-spacelift

open policy agent spacelift

You have the option to see everything that will be added/changed/destroyed directly from your VCS provider, or you can go to your Spacelift account and see everything in detail:

opa-spacelift-example

opa spacelift example

open-policy-agent-example

open policy agent example

Now, let’s attach a policy that verifies if our instance has a t3.micro shape. Here is the content of the policy:

opa-example

opa example

Now, if we retrigger a run, we can easily see that it will fail, because our instance has a t2.micro shape:

what-is-open-policy-agent

what is open policy agent

<h3>3) Manual approvals</h3>
Spacelift plan policies use a slightly different format from the one we used in our example policies earlier in this post. Not only do they allow you to specify a message to be displayed, but also have the concept of <code>deny</code> and <code>warn</code>:

The <code>deny</code> rule fails the run completely, while the <code>warn</code> rule just displays a warning in the logs.
<code>warn</code> rules take on another role when a run is going to deploy changes (vs just showing the planned changes against a PR). If any warnings are reported during a deployment, the run will wait for manual approval before applying any changes.
Let’s use the following example policy, designed to warn if an EC2 instance doesn’t have a shape we provide. To do this, we will just do a small change to the above policy (change deny for warn):

If we then attempt to add resources that don’t have that particular instance type, Spacelift will block before applying the changes and give us the chance to manually approve or deny the run:

policy-approval

policy approval

This allows you to build complex workflows where certain changes are completely blocked, while others are allowed as long as the changes are reviewed first.
Check out our policy library (available inside your Spacelift account → Policies → Account Templates) for more ideas about what policy templates are available, import them, and use them inside your workflow.

policy-library

policy library

Spacelift provides a <a href="https://registry.terraform.io/providers/spacelift-io/spacelift/latest/docs" target="_blank" rel="nofollow noopener">Terraform provider</a> for managing your Spacelift account. This means that you can manage the policies available within your account, along with the stacks they apply to in code.
For example, to add the policy we defined earlier to Spacelift we can use the <code>spacelift_policy</code> resource like this:

We can then attach this policy to a Spacelift Stack using the <code>spacelift_policy_attachment</code> resource:

Taking this a step further, we could create a custom module for defining Spacelift stacks that ensured that all stacks had a certain set of policies attached by default.

airtime-logo-white

Airtime Logo White

Several exciting tools can help integrate OPA with your systems. For example, Styra DAS allows you to write policies and deploy them across your infrastructure, as well as providing tools for unit testing, monitoring policy usage, and more. You can try OPA at scale for free using Styra DAS Free.

I hope you’ve enjoyed this post and can see the value that OPA brings to the table. If you’re interested in trying out <a href="https://spacelift.io/free-trial" target="_blank" rel="noopener">Spacelift to see what we have to offer, why not sign up for a free trial</a>? You can set up a Spacelift account in minutes, and get started on your policy-as-code experience today.

Spacelift is a flexible orchestration solution for IaC development. It delivers enhanced collaboration, automation and controls to simplify and accelerate the provisioning of cloud based infrastructures.

Kubernetes with Open Policy Agent (OPA) & Gatekeeper

What is Policy as Code (PaC) & How Do You Implement It?

What is Open Policy Agent (OPA)? See Open Policy Agent examples and a full tutorial on when to use it.

12-opa

Open Policy Agent

What is OPA? Open Policy Agent Examples & Tutorial

General

Learn what Policy as Code is, how it works, ands how to implement it. See the example with PaC tool Open Policy Agent.

Kubernetes

Learn what Open Policy Agent (OPA) is used for in Kubernetes. Gatekeeper vs OPA explained. See an example of OPA policy for Kubernetes.

Terraform import example and tutorial. Learn how to use the command to import a module, resource, and EC2 instance. Terraform import block explained.

Spacelift

Controlling infrastructure security while freeing developers is not the impossible balancing act you think it is. With policy-driven infrastructure as code (IaC), teams can achieve both without compromise.

In today's product demo webinar we’ll dive into common use cases of Spacelift policies and how teams are using them to achieve security and cost control of their infrastructure.