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 microservices authorization, to infrastructure-as-a-service controls — that are leveraged by millions of users.
Today, if you’re running Kubernetes, you know that security is not “built-in.” To secure your clusters, you have to configure, add or build in additional controls. Some are part of Kubernetes, like role-based access control (RBAC), but other best practices include specifying trusted repositories for known-good containers and then layering in runtime scanning tools as well.
Uptime. Reliability. Efficiency. These used to be perks, elements of forward-thinking and premium-level enterprises. Now they’re a baseline expectation. Today, consumers expect information, resources, and services to be available on-demand, updated in real time, and accessible without fuss. Imagine trying to Google something or place an order from Amazon only to be told, “Please try again in 48 hours. Sorry for the inconvenience.”
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.
