Styra DAS:
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. Using the DAS allows you to use a single language for expressing policy and a single software system for managing those policies across a broad spectrum of software systems, for example, Kubernetes, microservices, public cloud, Linux, and databases. The Styra DAS provides the world’s first enterprise-grade policy-development lifecycle including policy authoring, policy testing, policy distribution, policy monitoring, and policy logging.
The Styra DAS works with any software system integrated with OPA. It provides a core feature set that applies regardless of which underlying software system is integrated with OPA.
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).
Envoy:
Envoy is an L7 proxy and communication bus designed for large modern service-oriented architectures. Envoy is a self-contained process that is designed to run alongside every application server. All of the Envoys form a transparent communication mesh in which each application sends and receives messages to and from localhost and is unaware of the network topology.
Envoy originated as a service mesh sidecar proxy, factoring out load balancing, routing, observability, security, and discovery services from applications. In the service mesh model, requests flow through Envoys as a gateway to the network. Requests arrive at an Envoy via either ingress or egress listeners
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.
This tutorial shows 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:
1. Styra DAS Account, you can sign up for a free tenant here.
2. Kubernetes 1.14 or later
Now let us login into Styra DAS and create an envoy system.
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.
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.
Quickstart provides the link to install an 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.
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 that 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 visualize 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 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 the Decisions tab and verify traffic to the path /hr/dashboard and /admin are Denied.
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.
Modify the existing Ingress policy to allow traffic to the path /hr/dashboard. Quickstart provides the 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 the 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!
Summary:
Now, you have learned the following about Envoy with OPA and Styra:
Created 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. Installed sample application in the cluster and added ingress and egress policies in Styra DAS. Enforced, Validated, and Published the ingress and egress rules.