Getting Open Policy Agent Up and Running

Today, more organizations than ever use Open Policy Agent (OPA) as the de facto standard for policy enforcement across the cloud native stack. A graduated project from the Cloud Native Computing Foundation (CNCF), OPA has dozens of use cases — from Kubernetes guardrails, to , to infrastructure-as-a-service controls — that are leveraged by millions of users.

Whether an organization aims for a large-scale OPA use case, such as Atlassian, or wants to begin with a single OPA instance, teams need to walk before they can run. Here, we discuss how companies can create a robust policy-as-code lifecycle for OPA, allowing the company to then create repeatable processes that are scalable across teams, clusters and clouds. This is less about diving into the technical nuts and bolts of OPA as it is about establishing a framework that teams can use to get organized and get OPA up and running.

The key to rolling out policy-as-code in any organization is to understand that it’s just that — code. This means that the policies you enforce with OPA should enjoy a similar lifecycle as other software in your organization (and status as a first-class citizen). Such a process not only aids with initial OPA policy creation, but also allows the team to more easily scale OPA across other teams and processes, such as they might with CI/DC or DevOps processes.

Here are the basics of a robust policy-as-code lifecycle. The first step is to determine your requirements — where and how you will enforce OPA. This includes deciding your domain and enforcement points, such Kubernetes admission control or as an Envoy microservices sidecar. It also includes identifying the real-world organizational security and compliance policies that you will execute with OPA — typically stored in PDFs or simply in people’s heads. The next step, naturally, is to understand the data dependencies within your cluster or application that will be necessary to enforce those policies with OPA.

Next comes deploying and configuring OPA for your use case. There are many possible configurations of OPA — at the front of a cluster, for instance, or distributed as a proxy sidecar for microservices — so you may want to experiment with different deployment options to obtain the best latency performance for your needs. Along with that is a need to translate real-world policy into version-controlled policy in Rego, which is OPA’s policy language. Luckily, there are numerous resources to help new users get a handle on Rego and begin crafting modularized policy, from ample Rego documentation to training courses on Styra Academy.

While the first stage of the process is unique to OPA, this next phase, which we can deem “production,” will be familiar to most developers. Here, teams will round out the policy-as-code lifecycle with processes that are standard in typical DevOps or CI/CD workflows.

For instance, you will first establish a CI and testing phase, where you will assemble OPA policies into a single repository or library and perform unit tests and QA on policies to validate that they work as expected in live environments. This not only creates a safety net when building new policies, but it lends OPA credibility among security and compliance teams. Moreover, this allows you to create policy build artifacts or bundles, which can then be easily pushed to OPA deployments as part of a regular process.

At the deployment stage, you will simply deploy your policy-as-code to OPA as well as determine how regularly each OPA instance will refresh its data for decision-making. Meanwhile, you will also deploy common libraries to every OPA instance that depends on that particular library, allowing every instance to make good, consistent decisions.

At the penultimate stage, you will monitor and orchestrate your OPA deployments for OPA health, policy version and data version, just as you would with any other software or service in your organization. Finally, you will log OPA decisions for audit. Separating decision logging from normal application logging means that important decisions like those made around authorization are not lost in the noise of regular application events. Often, teams will feed OPA decision logs into other security and compliance pipeline tools, helping to prove that OPA did what it was supposed to do, and in ways that are understandable to non-technical members of the organization.

By building a policy-as-code lifecycle early on in your OPA deployment, you can not only ensure that your project takes off without a hitch, but build credibility among key stakeholders with a demonstrably robust process. Moreover, such a process provides the foundation needed to manage OPA at true scale — for instance, by easing the integration with processes such as GitOps, by allowing for the creation of policy libraries for non-technical users and by enabling centralized OPA policy deployments, which will eventually happen through a central OPA management plane.

While every OPA project is a journey, they all start at the same place — with a robust policy lifecycle and by instilling policy-as-code as a first-class citizen within the organization.

Get started with OPA with the Styra Academy! 

And, as always, If you have any questions, need help or have suggestions for improvements, feel free drop us a message on the Styra Community Slack!

This article first appeared in The New Stack on May 11, 2021.