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.