Getting Started with Kong Mesh and Open Policy Agent

Open Policy Agent, or OPA, is a policy engine that allows developer and operators to apply rules to common ways applications interact within an environment. Kong Mesh’s integration enables a common way to drive these policies between all service mesh workloads (Kubernetes, Virtual Machine, container workload). A simple example of an OPA policy could be using an OPA to control if a pod is allowed to be scheduled via the Kubernetes admission controller based on specific characteristics of the cluster or the submitting user. A more complex example could be applying a policy that controls filters DNS queries and responses against CoreDNS. OPA is highly extensible, and comes with a huge set of integrations out of the box across a growing number of tools within the application landscape. It allows users to get very granular at how they apply their authentication and authorization policies against workloads by creating a policy driven approach to interactions within application platforms.

For environments that require greater governance or management – Styra provides an enterprise offering for OPA. We’ll be diving more into how Styra provides a centralized management option for OPA at a later date – but a key capability to mention is that we also support integrating directly with Styra. Policies can either be applied directly to Kong Mesh (standalone), or Kong Mesh can reach out to a Styra server to pull down the applicable policies.

Let’s jump in on how to get started using it with a simple web application.

I’m running Kong Mesh in an Amazon Elastic Kubernetes Service (EKS) environment for this walk-through. We’re running a single zone deployment (all in the same cluster). The application we’re working with an application I threw together for various learning scenarios. It’s a 4-tier application with a Frontend, an API tier, a Redis database, and a PostgreSQL database.

Using OPA’s Envoy filters, we can start to apply policies to the interactions between our Frontend service and the API tier at a more “context” sensitive level. We can look at the content of the actual request, and make decisions based on that content. Let’s create a simple policy and dissect it.

The application I’m using supports issuing a JSON Web Token (JWT) to help with authorization across the application. In order to receive a valid JWT we need to issue a POST request to the loginEndpoint API. Once we’ve enabled the ability to POST – we’ll also want to configure OPA to be able to decode our issued JWT token to provide us the authorization details for the request. We’ll inspect the decoded JWT token to determine if the user who submitted the login is authorized to make POST request.

Let’s update our OPA policy to support this. We’ll update our OPA policy to be the following:

Now that we have the ability to get a JWT, this opens up additional things we can do with the token. In the case of this application, we’re giving it an expiration timestamp as well as a userid value. These values are generated by our API tier during the login process. Let’s make a couple final changes to our policy to allow us to take advantage of this data.

For the sake of brevity, we’ll add the following stanzas to the bottom of our OPA policy and reapply the manifest.

We’ve added 2 more policies within this addition that enable POST and DELETE methods when the decoded JWT includes the user_id value of “cody” (which is me, hi!).

Once we apply this policy, our application will be fully functional allowing us to login, post and delete messages. This communication is secured across the tiers using JWT tokens that are distributed from within our application – but decoded and evaluated by OPA living right alongside our service mesh workloads.

This walk-through has taken us through a basic use case of leveraging OPA policies to enable additional authorization and authentication policies across a multi-tier application. This capability allows us to intelligently control the way the application communicates versus the typical zero-trust approach of allowing or disallowing communication broadly. Envoy has many more filters that can be used to evaluate communication between tiers – but theres an ever growing amount of policies that extend beyond envoy communication that can be explored.