This blog post describes how to use OPA and Envoy to enforce authorization policies for a service. This is meant to demonstrate how dockerized services can easily use OPA in a non-Kubernetes environment.

The accompany code can be found at https://github.com/shanesoh/envoy-opa-compose

What is OPA and Envoy?

Open Policy Agent (OPA) is “an open source, general-purpose policy engine”. Your service queries OPA with some input and receives (usually but not necessarily) an allow/deny response.

Envoy is a proxy that runs alongside your service as a “sidecar” and implements common functionalities. As you’ll see below, we use Envoy to delegate authorization decisions to OPA by forwarding every request to OPA and then allowing/denying the request to the underlying service based on the OPA policy decisions.

Why OPA and Envoy?

We are fairly early in our journey of breaking up monoliths into purpose-built services that can be integrated easily and securely.

We chose OPA as it allows our teams to write their own authorization policies to meet rather complex access control requirements, while still providing some means of centralized management of authorization policies (via the bundles API) and a common language (i.e. Rego) for defining authorization policies (to facilitate audit or governance).

Envoy is purpose-built for sidecar usage with first-class Docker and Kubernetes support. Envoy filters, such as the External Authorization and JWT Authentication filters, can be used to implement functionalities common across services. As you’ll see later, we will use the External Authorization filter to have Envoy forward all incoming requests to OPA.

This is beyond the scope of the blog post: As we use OAuth2.0 access tokens to contain a user’s permissions, all services we build have to validate and decode access tokens. We then write OPA policies that allow/deny access based on data we get in the access tokens. In this setup it becomes important for individual services to verify the authenticity and validity of the access token. Envoy’s JWT Authentication filter does all this so that the upstream services won’t have to.

Envoy also future-proofs us while still being appropriate to our current state where most services run as docker containers in VMs rather than on Kubernetes. As we migrate services to Kubernetes, Envoy can be transparently tacked onto those services as sidecars. Envoy would also make a possible transition to a service mesh architecture smoother. For instance, we are currently utilising an API gateway to provide functionalities (like logging and monitoring) centrally, but if we see a lot of organic usage of sidecars by teams, it will be relatively easy to bring in Istio to provide better service mesh administration.

#microservices #envoy #open-policy-agent #docker