What is Open Policy Agent?
Open Policy Agent, or OPA, is an open source, general purpose policy engine. OPA decouples policy decisions from other responsibilities of an application, like those commonly referred to as business logic. OPA works equally well making decisions for Kubernetes, Microservices, functional application authorization and more, thanks to its single unified policy language.
So what’s a policy engine? And what’s policy?
What is policy?
A policy can be thought of as a set of rules. As such, any organization is going to have a number of policies in place, and even an organization without formal policies in place will still need to comply with regulations, agreements and laws. Simply put, policy is everywhere. In software systems, policy might describe things like:
What tables inside a database contain personally identifiable information (PII).
Which machines on a network should be considered trusted.
Expected salary ranges for employees based on years of experience.
Default resource allocation for new application deployments.
What roles are required to perform different actions in a system.
This last example of a policy is what we normally call authorization, and is a special type of policy that governs who gets to do what in a given system. In order to enforce authorization decisions, a process to establish the identity of the user must normally have been completed. This process is authentication, and while a distinct concept from authorization, authorization often depends on attributes retrieved in the authentication process, such as the roles a user may have, or whether multi-factor authentication (MFA) was used in the login process. This type of attributes is often referred to as claims.
What is a policy engine?
A policy engine is a software component that allows users (or other systems) to query policies for decisions. These decisions are commonly based not only on the policies loaded into the policy engine but also data from external sources such as permission databases or user management systems. This data might be provided as part of the query, loaded into the policy engine (asynchronously) before the query is sent, or fetched on-the-fly by the policy engine.
What is decoupled policy?
A policy engine allows decoupling policy decisions from other responsibilities of an application, like those commonly referred to as business logic. Decoupling policy from application logic comes with several benefits:
Policy may be shared between applications, regardless of the language or framework used by any particular application. This allows scaling policy enforcement even in diverse and heterogeneous environments such as those often found in larger enterprises.
Policy can be distributed from a central location, allowing centralized governance over what policies are deployed in an organization.
Policy lifecycle may (optionally) be decoupled from that of the application, allowing updates to be deployed without rebuilding and redeploying the application.
Policies can be tested in isolation. Since policy is code, it should be tested as any other software. Tests increase the confidence in the correctness of policies just as much as they help catch bugs and regressions when making policy changes.
Policies can be better understood by various stakeholders (e.g., other developers, IT and security officers, product managers, etc.) because the policy decision-making logic is not intertwined with application business logic.
Why Open Policy Agent?
Now that you know what a policy engine is, let’s look at the benefits of OPA compared to other alternatives:
Rego – Open Policy Agent uses a high level declarative language called Rego to describe policy. Rego makes it easy to build policy rules around hierarchical structured data, such as that represented in JSON or YAML, prevalent in almost all systems today. Having a purpose built policy language allows policy to be described succinctly using primitives and built-ins tailor made for policy. OPA includes more than 150 built-in functions to help author policies, including support for JSON Web Tokens, networking, cryptography, time and much more.
General-purpose – OPA can be used to express policies and rules against arbitrary structured data (JSON, YAML, etc.) Common use cases include application and microservice authorization, Kubernetes admission control, infrastructure policies and configuration management. OPA can be embedded as a library, deployed as a daemon, or simply run on the command-line. The general purpose nature of OPA allows organizations to deploy a single tool for policy enforcement across the cloud-native stack, whether it’s for their infrastructure, application authorization or Kubernetes admission control.
Cloud-native – OPA is a graduated project within the Cloud Native Computing Foundation (CNCF) along with other prominent cloud-native projects, such as Kubernetes, Envoy and Prometheus. OPA was built from the ground up to run in containerized, cloud native environments, and its lightweight nature allows it to be deployed in highly distributed environments, such as microservice architectures and serverless workloads. This doesn’t mean that OPA isn’t a good choice for more traditional environments. On the contrary, most of the benefits from being built for the cloud-native world applies just as much there.
Open source – All OPA code is released under a liberal Apache 2 license. This allows anyone to read and modify the source code to fit their needs, for personal user or commercial applications. In fact, several companies integrate OPA in their services and products!
Community and ecosystem – The general-purpose model of OPA, along with its open source licensing and its many qualities as a policy engine, has resulted in a thriving community and ecosystem to grow around the project. Check out the project on GitHub. Additionally, the OPA ecosystem page lists more than 50 integrations from both corporations and individuals in the community, covering use cases ranging from language integrations, data filtering and infrastructure tools, to build system integrations and service mesh addons.
Centralized management – OPA’s management APIs allow for OPA to pull policy and data bundles, report health and status and send decision logs, from/to a central control plane component, such as the Styra Declarative Authorization Service (DAS). This enables control, management and monitoring of OPA even in distributed environments with hundreds or thousands of OPAs deployed.
How to get started with Open Policy Agent?
There are many resources available to help you get started with OPA and Rego.
The OPA documentation is an excellent resource, both for learning Rego as well as a reference to use when authoring or reviewing policy. The documentation includes tutorials for many common applications of OPA, such as Kubernetes, Terraform, Envoy/Istio and application authorization.
The Rego Playground offers an interactive environment for learning and developing Rego policies entirely in the web browser. The playground includes example policies for most of the common policy contexts (application authorization, Envoy, Kubernetes), which is a great starting point for building more advanced rules and policies. Additionally, the playground allows evaluating policies with coverage, showing exactly which rules and lines are being evaluated given the input and data provided in the user interface. Lastly, the playground provides options for publishing policies online, either for sharing with others who might be able to help answer questions, or even to be served as bundles to OPA running on your own machine!
The Styra Academy provides an interactive learning environment combining video based tutorials with quiz style tests. The Styra Academy currently offers an extensive tutorial for learning Rego, and more topics coming soon! Make sure to check back every now and then to not miss anything in this top quality learning resource.
The OPA Slack is where the OPA community gathers to discuss all things OPA! Here’s your chance to ask any question to the people who built and maintain OPA, people with experience integrating OPA into the architecture of large enterprises, or simply just people who enjoy working with OPA. Just as much as we all learn from asking questions, we learn just as much by following along in the discussions others are having.
Finally, start small! While embracing a new paradigm such as policy as code may seem like a daunting task at first glance, much can often be accomplished with little effort. Some of the most used—and useful—policies, like checking if a user is an admin, if a deployment has enough replicas, or if a configuration resource is labeled correctly, can be built using just a few lines of Rego. Write a few rules, add some tests and grow your policy library as you learn.
As always, If you have any questions, need help or have suggestions for improvements, feel free to stop by the Styra Community Slack.