Open Policy Agent: Authorization for the Cloud

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 a service mesh.

OPA, an open source project, was launched four years ago and has steadily gained momentum as the de facto approach for establishing authorization policies across cloud native environments. Organizations use OPA for everything from controlling use of Kubernetes and microservices, to what resources can be checked into a CICD pipeline. As companies transition to production, they realize that they need a standard for security guardrails. OPA has become that standard across the stack.

In fact, many of the cloud native collaboration tools you’re using to work from home (such as the Atlassian suite and Chef Automate) employ OPA. So too are many of the apps we all enjoy for entertainment and connection, from the shows you’re streaming on Netflix, which are enabled in part by OPA, to the creative ideas shared on Pinterest.

Indeed, you can get a sense of the broad range of uses case for OPA from some of the sessions slated for KubeCon EU, including: “Handling Container Vulnerabilities with Open Policy Agent,” “CoreDNS and OPA for Policy-based, Multitenant Kubernetes Service Discovery,” “Help — my cluster is on the internet: Container Security Fundamentals,” and “A Governance Model for Policy as Code.”

While use cases for OPA abound, the following three are perhaps the most common today and may give you an idea of where you can get started:

• Application authorization. Virtually every application requires some form of authorization, and today that is typically achieved by corporate developers “rolling their own” code. Besides taking time and sapping resources, the result is a hodgepodge of tools that are hard to maintain. The code is important to the app, but it is heavy lifting and rarely adds anything to the “delight quotient” for end-users.

OPA enables you to accelerate time to market by providing pre-cooked authorization technology so you don’t have to develop it from scratch. It uses a declarative policy language purpose-built for writing and enforcing rules such as, “Alice can write to this repository,” or “Bob can update this account.” It comes with a rich suite of tooling to help developers integrate those policies into their applications and even allow the application’s end-users to contribute policy for their tenants as well.

If you have homegrown application authorization solutions in place, you may not want to rip them out to swap in OPA. At least not yet. But if you are going to be decomposing those monolithic apps and moving to microservices to scale and improve developer efficiency, you’re going to need a distributed authorization system and OPA is the answer.

• Kubernetes admission control. Another prominent use for OPA is to put guardrails around Kubernetes. Kubernetes has given developers tremendous control over the traditional silos of compute, networking and storage. And that, of course, is also the downside. Developers today can set up the network the way they want and set up storage the way they want. Administrators and security teams responsible for the well-being of a given container cluster need to make sure developers don’t shoot themselves (or their neighbors) in the foot.

OPA can be used to build policies that require, for example, all container images to be from trusted sources, that prevent developers from running software as root, that make sure storage is always marked with the encrypt bit, that storage does not get deleted just because a pod gets restarted, that limits internet access, etc.

OPA integrates directly into the Kubernetes API server, so it has complete authority to reject any resource — whether compute, networking, storage, etc. — that policy says doesn’t belong in a cluster. Moreover, you can expose those policies earlier in the development lifecycle (e.g. the CICD pipeline or even on developer laptops) so that developers can receive feedback as early as possible. You can even run policies out-of-band to monitor results so that administrators can ensure policy changes don’t inadvertently do more damage than good.

• Service mesh authorization. And finally, many organizations are using OPA to regulate use of service mesh architectures. So, even if you’re not embedding OPA to implement application authorization logic (the top use case discussed above), you probably still want control over the APIs microservices. You can execute and achieve that by putting authorization policies into the service mesh. Or, you may be motivated by security, and implement policies in the service mesh to limit lateral movement within a microservice architecture. Another common practice is to build policies into the service mesh to ensure your compliance regulations are satisfied even when modification to source code is involved.

A Unified Policy-Based Control for Cloud Native Environments

The community has shown us that people start with a single-use case and then expand as they grow comfortable. The ultimate goal is to put in place a unified approach to policy that gets you out of the job of mastering and caring for boatloads of different authorization models, each with their own APIs and GUIs.

Besides simplifying IT, a unified policy model will have broad implications for security (you won’t have 57 different tools to check if you think some unauthorized type of access was attempted), operations (is the service problem an authorization issue, or can you even tell?), and compliance (you won’t have to expend so much energy figuring out how to pull information from various systems to generate compliance reports in your heterogeneous environment).

So while we wait for KubeCon + CloudNativeCon Europe to hear from OPA users, you can use the time to learn more about policy-based controls for cloud native environments and arrive at the conference better prepared to find answers to your authorization issues. Additionally, the OPA slack channel is buzzing with questions and tips.

KubeCon, CloudNativeCon and CNCF are sponsors of The New Stack.

Feature image via Pixabay.