Open Policy Agent user survey validates need for cloud native authz

We recently surveyed the Open Policy Agent (OPA) community to gauge use case adoption, pain points and generally help guide the project. The recent survey results reflect how much the community has grown over the past year. This time we received 204 responses from over 150 organizations across North America, Europe, Asia, Australia and Africa. Over 90% of respondents indicated they are in some stage of OPA adoption (e.g., pre-production, production, etc.).

Open Policy Agent is everywhere

One of the biggest takeaways from the survey results (for us, as the original creators of the project) is that OPA is truly delivering on it's goal of providing a general-purpose, domain-agnostic building block for policy management. As we mentioned on the OPA blog, over half of respondent organizations use OPA for at least two use cases, with 29% using it for three or more use cases. These results are very encouraging because they back up the original goal of the project to empower that administrators with fine-grained control across the stack and that they should not be forced to manage policy through tribal knowledge, PDFs and wikis or complex, fragmented, ad-hoc implementations in each and every piece of software that they deploy.

So where is OPA getting used today? The survey results back up our anecdotal experience that Kubernetes admission control (and configuration validation in general) is still one of the most dominant use cases (with 54% of respondent organizations indicating they use OPA to enforce important guardrails on their platforms). However, the results also show that more and more organizations are leveraging OPA further up the stack within microservices APIs and applications themselves (36% and 43% of respondent organizations, respectively). The survey also reported that OPA is deployed widely in production for both Kubernetes admission control as well as microservice API authorization. Around 47% of respondent organizations indicate they use OPA to enforce a combination of ingress, egress and service-to-service policies on production microservices.

 

Build versus buy

All of these numbers are exciting, however it's important to remember that OPA is just a building block. OPA is focused on the expression and evaluation of policy. To this end, OPA provides a declarative language for expressing "policy-as-code" (Rego) and the corresponding runtime for evaluating and enforcing policies across your software stack. By design, OPA does NOT attempt to solve the rest of the policy management lifecycle. OPA (by itself) is not concerned with:

  • Exposing UIs for authoring and constructing policies.
  • Rolling out and managing policy across environments.
  • Collecting, aggregating, and reporting telemetry on policy decision-making.
  • Scanning environments to detect and remediate policy violations.
  • Validating policy changes using data gathered from live systems.
  • ...and much more.

Lately, the term "control plane" has become a popular way to describe these functions. Buzzwords aside, the important thing here is that a good control plane is key to operationalizing OPA and rolling it into production. Anecdotally, we find that new users are able to quickly get up-and-running with OPA—they can express the policies they care about and they can easily integrate OPA into their software. The burden of rolling their own policy language and engine is gone. This means they immediately begin focusing on higher-level (arguably more impactful) decisions around the rest of the policy management lifecycle. At this point, users have a number of build-vs-buy decisions to make.

Since OPA provides a set of well-defined APIs that enable control and visibility over the policy decision/enforcement point, users are able to build their own custom control planes on top of OPA. If you are interested, you can find great talks from companies like Netflix and Pinterest who have gone down this route in the past.

At the same time, implementing a policy management control plane is a lot of work! As the original creators of OPA, we believe that Styra Declarative Authorization Service (DAS) is uniquely positioned to help organizations efficiently manage policy across the stack. Styra DAS provides a complete OPA-based solution for policy authoring, distribution, impact analysis, auditing and more. Styra DAS accelerates an organization's time to production by providing:

  • Extensive policy libraries that codify best practices as well as standards like PCI-DSS.
  • Beautiful UIs for authoring and debugging any OPA policy.
  • Scalable and HA policy distribution services.
  • Powerful policy validation features like change impact analysis.
  • ...and much more.

 

Wrap up

These results are exciting and interesting and encouraging for the future of OPA. But more so for me, they are all exciting for the future of software! While our passion here at Styra is for authorization, we know that it is just one part of making software applications secure and performant. We hope that OPA can be the universal authorization solution for software teams everywhere—because that will free developers up to focus on innovation elsewhere.  

...And, hopefully, that means better, faster, more secure apps everywhere.

 

Want to learn more? Request a demo of Styra Declarative Authorization Service! 

 Prev

Microservices Authorization: Styra DAS Moves up the Stack

Next  

Unified cloud-native authorization: Policy everywhere and for everyone

Subscribe

API Authorization at the Gateway with Apigee, Okta and OPA (Part 1)

API gateways have become a standard..

September 24
Go

Why Microservices Require Unified Tools for Authorization

Cloud-native organizations embracing..

September 1
Go

Five OPA and Styra Trends that Prove Kubernetes Adoption

I’m often asked from people outside the..

August 27
Go