How companies like Netflix, Pinterest, Yelp, Chef, and Atlassian use OPA for ‘who-and what-can-do-what’ application policy. In the cloud-native space, microservice architectures and containers are reshaping the way that enterprises build and deploy applications. They function, in a word, differently than traditional monolithic applications.

Styra was founded with the simple premise that policy and authorization needed to be reinvented for the cloud-native environment. In order to secure and manage an exponentially more complex, containerized app development ecosystem, the team first had to build a new way to unify authorization policy at scale. The first step in achieving that was to create Open Policy Agent (OPA).

Open Policy Agent addresses Kubernetes authorization challenges with a full toolkit for integrating declarative policies into any number of application and infrastructure components. As more and more organizations move containerized applications into production, Kubernetes has become the de facto approach for managing those applications in private, public and hybrid cloud settings.

This is the second post in a two-part series about enforcing API authorization policies using Apigee, Okta and OPA. While the first post explained how to set up all three to work together, this post dives into detail on the policies that go along with the working code. The application we will be discussing is based on a hypothetical medical insurance provider Acme Health Care.

API gateways have become a standard component in modern application architectures. The gateway exposes application APIs to the Internet and serves as a logical place to enforce policy. This is a two-part series about enforcing API authorization policies in Apigee with Okta as the identity provider (IdP).

Cloud-native organizations embracing microservices are running into an unavoidable security question: how to handle microservice authorization controls? The central problem is this: unlike monolithic app structures, microservices architectures expose dozens more functionality through APIs, which can leave them vulnerable to attack.

I’m often asked from people outside the cloud-native space how the market is progressing and if Kubernetes is taking off or not. My answer is always the same: Kubernetes is absolutely the de facto approach to managing containerized applications, and, because of that, the market is expanding exponentially. We’re almost two-thirds of the way through 2020, and in the cloud-native space, it’s so far been the year of Kubernetes.

I witnessed the transition from bespoke authentication to standards-based authentication. It’s time to do the same for authorization. Twenty years ago, almost everything in the IT world was on-premises: hardware and software, including the tools you used to verify who your users were and what they could do in your systems.

When we started Styra, we set out to rethink authorization and policy for the cloud-native environment. We knew that new risks and challenges would emerge as companies embraced the cloud and began using a whole new host of technologies and architectures for building applications. The constant changes and dynamic runtime of the cloud-native environment complicated matters even more.

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.).