In November 2019, just after Styra raised $14 million in our Series A funding round, I wrote that the market’s move away from monolithic apps and adoption of containerized cloud-native application architectures was going to provide “a substantial market opportunity for policy and authorization to evolve.” A lot has happened since I wrote that, and I’m happy to report that while our Series A round showed the market opportunity, our latest round of funding proves the validity of t

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? A policy can be thought of as a set of rules.

Kubernetes developers and platform engineers are typically under a metric ton of pressure to keep app deployments humming at a brisk pace. With the scale and power of Kubernetes, this can feel daunting. Maybe you’re a retailer launching a new e-commerce feature for a huge sale. Maybe you’re a bank that’s scaling a finance app worldwide. In either case, compromises always get made in the interest of speed and schedules.

Companies have moved to cloud native software development so that they can increase development speed, improve product personalization, and differentiate their buyer experiences in order to innovate and win more customers. In doing so, enterprises have also redefined how they build and run software at a fundamental level.

If you’re responsible for a microservices app, you may be familiar with the idea of a “latency budget.” This is the maximum latency, measured as total request time, that you need for the app to work, in order to meet your SLAs and keep stakeholders happy. For a stock trading or financial services app, this budget might be the barest of microseconds.

Bridging the gap between Security, Compliance and DevOps teams can be a challenging cultural shift to address. DevOps teams are eager to get software out faster and more efficiently, yet security best practices, like policy-as-code, need to be integrated from the outset to streamline the development process in this new cloud-native world.

A question that comes up every now and then is whether it’s possible to compose policies based on dynamic attributes provided with the request when querying Open Policy Agent (OPA) for decisions. Could we for example provide a group, team or role name as part of the input and have OPA evaluate all policies provided for that group, team or role, but no additional policies other than those? Imagine you have several teams in an organization, each of them with their own responsibilities.

Whether you’re just starting to understand basic Rego language concepts or want to brush up on structuring policy-as-code rules, Styra Academy’s “OPA Policy Authoring” course lays out the fundamentals you need to know to get started. Before we dive in, let’s get a better understanding of Open Policy Agent (OPA) and some common use cases. OPA is an open source, general purpose policy engine for cloud native environments.

As part of Styra’s vision for unified authorization, we founded the Open Policy Agent project (OPA) to make policy-based control of the cloud-native stack accessible to everyone. OPA has now grown to become the de facto standard for authorization across the stack, leading to a large part of the community looking for ways to manage the OPA policy-as-code lifecycle.

This post is going to outline some basics, interesting tidbits and caveats on unit testing Rego policies.