Open Policy Agent (OPA) is a valuable tool for creating and managing cloud-native policies. The open-source policy engine helps unify policy management for today’s distributed service architecture, fitting nicely with cloud-native environments like Kubernetes, containers, service mesh, and application programming interfaces (APIs).

“With OPA, you can work with policies as you would with any type of code,” said Anders Eknert, Developer advocate, Styra. “You must know code to modify policies, but compared to policy management in a PDF document, it’s a big step in the right direction.”

Attend the Platform Summit 2023 to catch Ander Eknert’s session.

Ahead of this year’s Platform Summit, we’re catching up with a few key speakers to explore their upcoming talks and get their perspectives on trends in the API industry.

Anders Eknert, a veteran Nordic APIs speaker, has had deep experience working with identity and security-related standards for distributed systems, from Bisnode to Curity. Now at Styra, Eknert is a developer advocate and a member of the Open Policy Agent team.

I recently caught up with Eknert to explore using OPA for API authorization, a theme of his upcoming session. Below, we’ll discover the benefits of using OPA to create and manage API policies and see how it can help eable a zero-trust approach for API security.

For those that still may be unfamiliar, what is OPA?

OPA is an open-source distributed policy engine that lets you define rules to work with various systems, described Eknert. OPA, a Cloud Native Computing Foundation (CNCF) graduated project, is a general-purpose tool for many types of policy requirements but works exceptionally well for authorization. In OPA, policies are written in Rego and are enforced by the OPA Policy Engine.

What is the gap with traditional API gateways? How does OPA advance the old ways?

According to Eknert, the traditional API gateway faces a significant gap when compared to the demands of today’s complex software environments. The old gateway model managed authorization only at a single point, but this approach doesn’t work well within the new highly regulated zero-trust distributed environments.

Authorization decisions are made all the time and everywhere, explained Eknert, and these decisions must be decoupled from applications — similar to how a centralized identity server is decoupled from end applications. OPA builds on the older model, advancing the notion of only doing security at your system’s perimeter.

The shift toward zero-trust architecture is important, because there are often no protections if you make it past a firewall or gateway, said Eknert. Nearly 80% of API endpoint attacks come from users that appear legitimate but who have maliciously achieved the necessary authentication, found a Salt Security report, meaning an ongoing vigilance is integral to continuous compliance.

How can you use OPA to create and manage API policies?

To enact policy management, OPA works as a distributed component that runs next to applications. For example, in Kubernetes it would run as a sidecar in a container in the same pod of the service. When OPA receives a request, it reaches out to a centralized location to examine policies, report the status, and log its decision. A centralized control plane helps to manage policies incrementally and provision updates. (Styra also provides a commercial control plane to address this at scale).

How fine-grained are these policies? Well, it could be a simple role-based access control (RBAC) model. But Eknert has seen authorization policies in banking applications with 12,000 lines of Rego! There’s much customization potential in OPA, including the ability to integrate with other types of data sources, or to enforce temporal constraints and other conditions that could affect the policies.

Can OPA work with various API styles?

By decoupling policy management, you can more easily apply the same policies to heterogeneous environments, said Eknert. These could be internal, partner, or third-party APIs, or applications written in different programming languages. There are built-in functions to work with GraphQL as well as plugins to support other styles, although most integrations tend to be REST APIs.

For example, this example HTTP API use case explains how to code a policy that enables people to see their own salaries, and for a manager to see their direct reports’ salaries. The following policy, written in Rego, defines the proper context to enable the engine to make the correct authorization decision at runtime.

package httpapi.authz

# bob is alice's manager, and betty is charlie's.
subordinates := {"alice": [], "charlie": [], "bob": ["alice"], "betty": ["charlie"]}

default allow := false

# Allow users to get their own salaries.
allow {
    input.method == "GET"
    input.path == ["finance", "salary", input.user]
}

# Allow managers to get their subordinates' salaries.
allow {
    some username
    input.method == "GET"
    input.path = ["finance", "salary", username]
    subordinates[input.user][_] == username
}

What does the future of OPA look like, and what is the team working on lately?

OPA is an active and vibrant open-source initiative with nearly 400 contributors and over 8,000 stars on GitHub. There are also countless official and community-supported libraries that bring OPA support into various platforms and languages.

Regarding new features, Eknert highlighted the new linter for Rego. Using a Rego linter will ensure policies conform to the language, offering best practices and tips to improve. “This is going to help people become more comfortable with Rego,” he said.

For the rest of this year, OPA’s project roadmap also has sets sights on a number of features to support various language mechanics, new tools, and performance enhancements.

On the commercial side, Eknert highlighted new advances in Enterprise OPA, which he said will enable much better performances and resource utilizations for policy management.

Why are you excited about Platform Summit 2023?

“Nordic APIs’ Platform Summit 2019 was the first conference I ever talked about OPA at,” said Eknert. “Back then, I had taken a look at OPA and forced myself to learn about it for the presentation. Four years later, I’m excited to go back to my roots.”