In this blog, you will learn how to add a policy in Styra DAS to Integrate Envoy with OPA and Styra.
OPA (Open Policy Agent):
The Open Policy Agent (OPA, pronounced “oh-pa”) is an open-source, general-purpose policy engine that unifies policy enforcement across the stack. You can use OPA to enforce policies in microservices, Kubernetes, CI/CD pipelines, API gateways, and more. OPA was developed by Styra and is currently a part of the Cloud Native Computing Foundation (CNCF).
Styra DAS (Declarative Authorization Service):
The Styra Declarative Authorization Service (DAS), built on top of the open-source project Open Policy Agent (OPA), provides a single pane of glass for authorization and policy across the cloud-native ecosystem of software systems.
The Styra DAS works with any software system integrated with OPA.
It is a single control plane to build, test, distribute and monitor authorization policy.
Styra Declarative Authorization Service (Styra DAS) is the fastest and easiest way to operationalize Open Policy Agent (OPA) across Kubernetes, microservices or custom APIs.
What Is Envoy?
Envoy manages the ingress and egress network traffic permitted within your Envoy-based service mesh. It is a Layer 7 proxy and communication bus designed for large modern service-oriented architectures.
Envoy Architecture:
Ingress listeners take requests from other nodes in the service mesh and forward them to the local application. Responses from the local application flow back through Envoy to the downstream.
Egress listeners take requests from the local application and forward them to other nodes in the network. These receiving nodes will also be typically running Envoy and accepting the request via their ingress listeners.
Envoy version v1.7.0 and later supports an external authorization filter that calls an authorization service to check if the incoming request is authorized or not.
In this, you will learn about how Envoy’s external authorization filter can be used with OPA as an authorization service to enforce security policies over API requests received by Envoy. 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.
Prerequisites:
- Kubernetes 1.14 or later
- Styra DAS Account, you can sign up for a free account here.
Now, let us login into Styra DAS and create a Envoy system.
Steps : –
Create an Envoy System.
Install Styra CLI and deploy the Styra Local Plane (SLP), OPA Config and Envoy Config on the System.
Add and publish the rule.
Audit the Decisions.
Modify the Policy and Check the Decisions.
Step 1 : Create a New Envoy System:
Systems are displayed on the left side of the navigation panel. To add a new system, click the + next to SYSTEMS on the left side of the navigation panel.
Step 2: Install Styra CLI and deploy the Styra Local Plane (SLP) , OPA Config and Envoy Config on the 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.
Quick start provides the link to install the example application. When you run the Envoy example application, the OPA sidecars will pull down the policy from the DAS tenant and start enforcing it.
Envoy Example Application:
example-app: 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 employees who are part of HR. Functionally, it is a simple echo server that returns a HTTP 200 response with a plain/text body which contains a success or error message.
client-load: 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 visualise the impact of the configured Egress and Ingress policies by simulating traffic to the example-app.
SLP: Styra Local Plane (SLP) is a service that acts as an intermediary between the OPAs and Styra DAS. OPAs are configured to retrieve bundles from SLP rather than directly from DAS. This increases availability as SLP fetches bundles from Styra DAS and persists them to disk, so policies are still available to new or restarted OPAs even if Styra DAS is unavailable.
After installing the example application, we can check the pods are running in the cluster.
The client-load deployment repeatedly executes the following HTTP calls in an interval of 30 seconds, pretending to be different users to help generate sample data for visualization.
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. You could click on Decisions tab for the Envoy system created and verify all the Allowed decisions.
The Envoy system Quick Start provides a link 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 Decisions tab and verify traffic to path /hr/dashboard and /admin are Denied.
Step 3: Add and Publish the Rule
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]
}Now, click on validate. The Validate button will tell you what percentage of past decisions will be changed by your new policy.
This policy lets you allow only the ingress connections on endpoint “/finance/salary{user}” in example-app, all other ingress requests are denied.
Now publish your policy and check the changed decisions.
Step 4: Audit the Decisions:
Step 5: Modify the Policy and check the Decisions:
Modify the existing Ingress policy to allow traffic to path /hr/dashboard. Quick start provides link for modifying the policy in step Modify and test your 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]
}# allow /hr/dashboard ingress
allow {
input.attributes.request.http.method == "GET"
input.parsed_path = ["hr","dashboard"]
}Again validate and publish the policy. The decisions for path /hr/dashboard are now marked as Allowed.
By default, egress policy allow all requests, now replace below egress policy under policy folder >> egress >> rules.rego.
package policy.egress# Add policy/rules to allow or deny egress trafficdefault allow = falsedeny {
input.attributes.request.http.method == "GET"
input.attributes.request.http.path == "/finance/salary"
}
deny {
input.attributes.request.http.method == "GET"
input.attributes.request.http.path == "/hr/dashboard"
}Validate and publish the policy. We can see egress traffic will be denied for GET requests under the path /finance/salary and /hr/dashboard.
Congratulations!
Now, you have learned the following about Envoy with OPA and Styra.
Summary :
Added an Envoy system in Styra DAS and downloaded and deployed the Styra Local Plane (SLP), OPA config and Envoy config on the machine to integrate with Styra DAS. Written policies, distributed policies to OPA, and managed the decisions made by OPA. Finally Validated, Enforced and published the ingress and egress policies on Styra DAS. OPA-Envoy integration gives you fine-grained access control over microservice API authorization.