Styra DAS, OPA, and Envoy Integration Give You Fine-Grained Access Control Over Microservice API Authorization.

What is Envoy?

Envoy is an L7 proxy and communication bus designed for large modern service-oriented architectures. Envoy supports an External Authorization filter which calls an authorization service to check if the incoming request is authorized or not. This feature makes it possible to delegate authorization decisions to an external service and makes the request context available to the service.

Image Source: StyraDAS with ENVOY

What is OPA?

Open Policy Agent (OPA) is an open-source, general-purpose policy engine created by Styra that enables unified, context-aware policy enforcement across the entire stack. OPA’s high-level declarative language Rego allows the authoring of fine-grained security policies and is purpose-built for reasoning about information represented in structured documents.

Prerequisites:

  1. This tutorial requires Kubernetes 1.20 or later. To run the tutorial locally, we recommend using minikube in version v1.21+ with Kubernetes 1.20+
  2. Kubernetes cluster (You can create a Kubernetes cluster using K3D)

3. A Styra DAS account is required for this tutorial.

4. Note: If you don’t have a Styra DAS tenant, you can sign up for a free tenant here(Signup)

Steps for creating cluster by using K3d:

What you’ll need

  • 2 CPUs or more
  • 2GB of free memory
  • 20GB of free disk space
  1. All you need is Docker (or similarly compatible) container.
  2. Install the latest release of K3D and kubectl.
wget -q -O - https://raw.githubusercontent.com/rancher/k3d/main/install.sh | bashsnap install kubectl --classic

3. Finally, create a Kubernetes cluster with the below command.

k3d cluster create (name of the cluster)

Steps for creating cluster by using minikube:

For this tutorial, you must have a Kubernetes cluster available. For testing and evaluation purposes, you can start with the Kubernetes minikube.

  1. Download and install Kubernetes (minikube), if necessary. Use minikube for this tutorial, and use the following steps to set up a test environment.
  • Verify that virtualization is supported.
  • Install kubectl.
  • Install a virtualization Hypervisor.
  • Install minikube.

Start the minikube service by running the following command:

minikube start

Confirm the installation by running the following command:

minikube status

The following output is displayed only when your cluster is installed and running.

host: Running
kubelet: Running
apiserver: Running
kubeconfig: Configured

Create a New Envoy System:

In StyraDAS Adding new System i.e Envoy

Install the Envoy System:

To install Styra on Envoy, you must copy and paste all the four installation commands from SYSTEMS >> Settings >> Install for your Envoy system into your terminal. This will download and deploy the Styra Local Plane (SLP), OPA config, and Envoy config.

Install Styra on ENVOY

Quick Start provides the link to install the example application. It consists of the following components, which should now be running in your minikube. All resources are suffixed by the SYSTEM ID to mark them as unique.

Quick Start helps to find Example Applications in Styra DAS

Install the Envoy Example Application

First Login to StyraDAS, then click on QuickStart(?)Icon:

Quick Start provides the link to install the example application. It consists of the following components, which should now be running in your minikube. All resources are suffixed by the SYSTEM ID to mark them as unique.

StyraDAS by default provide some sample Applications

→Download and deploy a demo setup with pre-configured OPA and Envoy sidecar containers using the command below:


curl -H ‘Authorization: Bearer ZNMPj3ny-lm7cmbcsDPAVpk3XXXXXXXXXXXXXXXXkqT3oJMJ4mwVZrqQKAP-o4’ https://<yourtenentid>.svc.styra.com/v1/system-types/template.envoy:2.0/assets/quickstart/example.yaml | kubectl apply -f -

The demo setup consists of two deployments: client-load and example-app, each of them has OPA and Envoy containers as sidecars.

The OPA and Envoy containers have mounted volumes for the config maps containing OPA and Envoy configuration.

proxy-init container installs IP table rules to redirect all container traffic through envoy proxy sidecar

example-app is a simple HTTP web server that allows employees of a hypothetical organization to obtain salary details at the path /finance/salary. It also exposes a path /hr/dashboard that is only accessible by HR employees.

Client-load is a simple shell script that generates some pre-configured HTTP GET requests to test the behavior of the deployed policy. It helps generate data to visualize the impact of the configured egress and ingress policies by simulating traffic to the example-app.

Envoy Example Application deployment YAML file (passwords rotated for safety reasons)

NOTE: a sample Kubernetes deployment manifest with pre-configured OPA and envoy sidecar containers can be downloaded using the command provided in the last option of the Install pane. Unlike the demo setup provided above, this manifest does not contain the main application, and you are expected to provide it.


curl -H ‘Authorization: Bearer 7LOimHYUXXXXXXXXXXXXXXXXFRcaBr-ArHisOjIvDbs3ot2***********4e4iaWsz03JOUXPwjfXFbHA-A’ -o opa-envoy-deployment.yaml https://<yourtenentid>.svc.styra.com/v1/systems/ad4e798c5df34d5dabac92a400a78f7f/assets/opaEnvoyDeployment.yaml

Author your first policy:

Insert your rego policy

Policy


package policy.ingressdefault allow = false# allow /finance/salary/{user} ingress
allow {
  some username
  input.attributes.request.http.method == "GET"
  input.parsed_path = ["finance", "salary", username]
}
Replace Policy, Validate and Publish →Policy /changes/replayed

Enforce the Ingress Policy

For ingress policy type, click your Envoy system to expand the policy folder >> ingress >> rules.rego to see the ingress rules for your Envoy system.

The client-load deployment repeatedly executes the following HTTP calls in 30 seconds, pretending to be different users to help generate sample data for visualization.

Copy the below commands and paste them in your terminal/instance:


curl --user alice:password example-app/finance/salary/alice
curl --user bob:password example-app/finance/salary/alice
curl --user bob:password example-app/finance/salary/charlie
curl --user david:password example-app/finance/salary/bob
curl --user david:password example-app/hr/dashboard
curl --user eve:password example-app/admin
curl -is httpbin.org/anything;

By default, all policies allow traffic to the service with the Envoy data plane as a sidecar container. For example, you could click on the Decisions tab for the Envoy system created and verify all the Allowed decisions.

Envoy system created and confirmed all the allowed decisions.

The Envoy system Quick Start links to replace the sample Ingress policy. With this Ingress policy published, example-app can receive Ingress traffic only on the whitelisted endpoint /finance/salary. Switch to the Decisions tab and verify traffic to the path /hr/dashboard and /admin are Denied.

/hr/dashboard and /admin are Denied.

Validate the Ingress Policy:

ENTERPRISE

Modify the existing Ingress policy to allow traffic to the path /hr/dashboard. Quick Start provides a link for modifying the policy in step Modify and test your policy. To determine the effect of policy, click Validate. You will see new panes, Tests, and Decisions. The Decisions pane displays the change caused by replaying past decisions with the updated policy. The decisions for the path /hr/dashboard are now marked as Allowed.

Policy:

package policy.ingressdefault allow = false# allow /hr/dashboard/{user} ingressallow {
 some username
 input.attributes.request.http.method == “GET”
 input.parsed_path = [“hr”, “dashboard”, username]
}
The decisions for path /hr/dashboard are now marked as Allowed.

Summary:

Now, you have learnt the following about Envoy with OPA and Styra:

  • The OPA-Envoy integration gives you fine-grained access control over microservice API authorization.
  • You can use Styra to write policies, distribute policies to OPA, and manage the decisions made by OPA.
  • It also covers examples of authoring policies over the HTTP request body. It is based on the HTTP API Authorization OPA tutorial with added policies to control the ingress or egress behavior of the application and client.

References:

Here are some ideas for your next adventure.

Styra Academy →Learn more about policy authoring at the Styra Academy — it’s FREE!

OpenPolicyAgent. →The OPA website lets you find OPA documentationdownloads, and the OPA Blog.

The Rego Playground. →Rego (pronounced “ray-go”) is OPA’s policy language. You may view policy examples using the Playground, execute policies with input and data, and publish your policies to share and collaborate.

Styra DAS Free →Where you may sign up for a free trial of Styra DAS, Styra DAS is a great way to get started using OPA as it provides sample apps sample policies, in addition to quickstarts that allow you to spin up new OPA’s for common use cases.