As cloud infrastructure scales, governance, security, and compliance become more complex. Policy-as-Code provides a powerful solution by automating and enforcing policies consistently across Infrastructure-as-Code (IaC).

Join Omry, CTO of env0, and Andres, Lead Developer Advocate at Styra, for a 30-minute lightning talk exploring the role of policies in IaC, real-world enforcement examples, and the latest updates in Open Policy Agent (OPA).

Watch the full discussion below:

Omry: Welcome to the webinar. My name is Omry. I'm the CTO and co-founder of env0. env0 is the platform to manage all of your Infrastructure-as-Code. And today we are going to talk about Open Policy Agent and Policy-as-Code, and how they interact with Infrastructure-as-Code. With me today is Andres from Styra. Great to have you here.

Andres: Thanks, Omry. Happy to be here. I'm Andres. I lead developer relations at Styra. I've been involved with OPA for nearly six years now, both as an end user and now working at Styra. Before that, I worked in identity systems, which is what got me interested in OPA—once you know who someone is, the next question is, what can they do?

At the time, I was on a platform team, and we needed ways to enforce security rules, restrict deployments, and prevent accidental mistakes. That’s how I got into OPA. I think one of the most interesting aspects of policy, especially for infrastructure, is that it often protects you from yourself.

Security is a concern, of course, but most of the time, the biggest risk is human error—misconfigurations, unintended actions, and mistakes that could be costly or embarrassing.

Omry: That’s a great point. Policies exist everywhere, even outside of tech—in workplaces, families, and everyday interactions.

When we use SaaS platforms like Gmail or GitHub, we interact with policies all the time. For example, on GitHub, you can’t merge a pull request unless certain checks pass or someone approves it. That’s policy enforcement at work.

The same logic applies to infrastructure—because mistakes can be costly, we need policies in place to control deployments and enforce security and compliance.

Andres, can you talk a bit about how Styra and Open Policy Agent help with this?

Andres: Absolutely. Policies exist whether we like them or not—they’re everywhere, built into systems we use daily.

The core idea behind Open Policy Agent (OPA) is that there should be a unified way to define policy across different use cases and environments. Many companies use separate tools for authorization, infrastructure policy, and security enforcement. But using different tools for essentially the same thing adds complexity and cost.

OPA provides a common policy engine that can be applied consistently across different domains.

Technically, OPA allows you to load policy rules and data, then query them to make decisions. For example, an access control rule might state, a doctor can view medical records only for their own patients.

When a query comes in—can this doctor view this patient’s records?—OPA evaluates the rules and returns a decision. In infrastructure, policies might say, you cannot deploy an S3 bucket that is publicly accessible or deployments costing more than $100 require approval.

OPA evaluates these rules and enforces them before changes are made.

Omry: That makes a lot of sense. Infrastructure as Code is a powerful tool, but it also introduces risks—security issues, cost overruns, and misconfigurations.

For example, you might want to enforce tagging policies to track resources by team or require approval before deploying to production. OPA provides a standard way to do this within your CI/CD pipeline.

Can you also talk about Rego, the policy language used in OPA?

Andres: Sure. Rego is a policy language designed specifically for OPA.

One of the common questions we get is, why not use Python or JavaScript?

The answer is that general-purpose programming languages don’t have the same security guarantees—like preventing infinite loops or restricting filesystem access. Rego is optimized for policy writing. It reads like a set of rules rather than complex code.

For example, a simple Rego rule might state, allow access if the user is an admin or on-call. The latest updates to Rego make it even more readable and concise.

Omry: That’s great. Let’s look at a practical example.

Many of our customers use OPA for approval workflows.

For instance, if a team wants to deploy something to production, a policy might require approval from the DevOps team. If it’s a security-sensitive change, approval might be required from the security team.

Policies can also enforce cost controls—blocking deployments estimated to exceed a certain budget or requiring additional approvals.

Can you share some real-world examples from Styra’s customers?

Andres: Absolutely. The two main use cases we see are access control and infrastructure policy.

With access control, policies are usually private—banks and financial institutions don’t share their security policies publicly.

But with infrastructure policies, there’s a lot more transparency. Infrastructure follows common standards—an S3 bucket is an S3 bucket, regardless of the company. That makes it easier to share and reuse policy templates.

For example, companies use OPA to prevent misconfigurations like publicly accessible S3 buckets or unsecured Kubernetes pods. Many policies are already written and available in open-source repositories, making it easy to get started without reinventing the wheel.

Omry: That’s a great point. In the Infrastructure as Code community, a lot of knowledge is shared—whether it’s Terraform modules or OPA policies.

Before writing a policy from scratch, check if someone has already done it—it could save a lot of time.

Now, I know OPA 1.0 was recently released. Can you tell us about the key changes?

Andres: Yes! OPA 1.0 was released in December. While it’s a major version, most changes are refinements rather than overhauls.

The goal was to improve usability and readability without breaking compatibility.

For example, we focused on improving readability and usability, ensuring policies are easier to manage, easier to read, and easier to write. In the past, a simple policy might take 20 lines of code—now, it can be expressed in a more compact, intuitive way.

We also made sure upgrading is seamless—if you have older policies, they will still work without modification.

Omry: That sounds like a great update. Now, let’s talk about env0 and how we integrate with OPA.

At env0, we provide a way to manage Infrastructure as Code at scale. Within our platform, each project is assigned to a cloud account with specific role-based access controls. One key feature we offer is policy enforcement.

Users can connect OPA policies stored in a GitHub repo, define inheritance rules, and apply policies across multiple projects. For example, a parent project can enforce a policy that applies to all child projects automatically.

Let’s walk through an example. Suppose a company has a policy that requires approval for any deployment exceeding $15. When a user initiates a deployment, env0 fetches cost estimates from Infracost and checks them against OPA policies.

If the deployment is expected to cost $28, approval is required from the FinOps team. In this case, two approvals are needed. The team receives a Slack notification and can review the request before approving or canceling it.

We also support auto-approval for deployments that don’t introduce any changes. Users can define flexible rules based on their needs, ingesting data into OPA, and making policy decisions in real-time.

Omry: Thanks, Andres! And thanks to everyone who joined us today. If you’d like to learn more, visit env0.com. See you next time!

‍