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

We’ve had an exciting past six months at Styra, from a Series A funding announcement to tremendous growth in the Open Policy Agent (OPA) community to new enhancements to our commercial product, Styra’s Declarative Authorization Service (DAS). All of this great momentum maps to our overarching vision of unifying authorization and policy for the cloud-native environment.

Talks focused on Open Policy Agent (OPA) are featured prominently in the agenda for KubeCon + CloudNativeCon Europe—15 OPA-focused sessions were accepted from users at Google, City of Ottawa, Ada Health and more—signaling the importance of authorization in the cloud. While the event and those talks are now on hold until August, that doesn’t mean we should postpone learning more about authorization within applications, across Kubernetes clusters and on top of service mesh.

It’s clear from the latest Cloud Native Computing Foundation survey that containerized environments have become mainstream, increasing automation at scale for companies. But, in the cloud-native environment, changes are constant and runtime is extremely dynamic. And while automation can help eliminate manual work, it can also replicate mistakes and risk at cloud scale.