In this blog, you will learn how OPA embedded in the Istio data plane can be used as an authorization service to enforce security policies over API requests received by Istio.
What is Istio?
Istio is an open-source service mesh that layers transparently onto existing distributed applications. Istio’s powerful features provide a uniform and more efficient way to secure, connect, and monitor services. Istio is the path to load balancing, service-to-service authentication, and monitoring — with few or no service code changes. Its powerful control plane brings vital features, including:
- Secure service-to-service communication in a cluster with TLS encryption, strong identity-based authentication, and authorization.
- Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
- Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
- A pluggable policy layer and configuration API supporting access controls, rate limits, and quotas.
- Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
Adding a proxy “sidecar” along with every application deployed, Istio lets you program application-aware traffic management, incredible observability, and robust security capabilities into your network.
How it Works:
Istio has two components: the data plane and the control plane.
The data plane is the communication between services. Without a service mesh, the network doesn’t understand the traffic being sent over and can’t make any decisions based on what type of traffic it is or who it is from.
Service mesh uses a proxy to intercept all your network traffic, allowing a broad set of application-aware features based on the configuration you set.
An Envoy proxy is deployed with each service you start in your cluster or runs alongside services running on VMs.
The control plane takes your desired configuration and view of the services and dynamically programs the proxy servers, updating them as the rules or the environment changes.
Envoy proxies are the only Istio components that interact with data plane traffic.
Istiod provides service discovery, configuration, and certificate management. In addition, Istiod acts as a Certificate Authority (CA) and generates certificates to allow secure mTLS communication in the data plane.
In this tutorial, you will learn how OPA embedded in the Istio data plane can be used as an authorization service to enforce security policies over API requests received by Istio. 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.20 or later.
- Istio 1.9.2 or later.
- Styra DAS Account, you can sign up for a Free Account here.
Create an Istio System:
To demonstrate the enforcement of ingress and egress policies for a sample application, you can start by creating a new Styra Istio system. Systems are displayed on the left side of the navigation panel. To add a new Istio system, click the + next to SYSTEMS on the left side of the navigation panel.
Now, you will see the instructions to install an example application onto your cluster.
Install Example Application:
Be sure kubectl is configured to point to the cluster with the Istio control plane deployed.
To install Styra on Istio, you must copy and paste all the four installation commands from SYSTEMS >> Settings >> Install for your Istio system into your terminal. Enable Istio sidecar injection on the default namespace, create envoy filter, OPA config, and deploy Styra Local Plane (SLP). For deploying it on the custom namespace, make sure Istio sidecar injection is enabled for the custom namespace.
The Istio system QuickStart provides the link to install an 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/dashboardthat is only accessible by employees who are part of HR. Functionally, it is a simple echo server that returns an 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. Hence, policies are still available to new or restarted OPAs even if Styra DAS is unavailable.
- Each application has an Istio proxy and OPA as a sidecar container.
When you run the Istio example application, the OPA sidecars will pull down the policy from the DAS tenant and start enforcing it. This process takes a few minutes to complete.
After installing the application, you can check the pods running in your cluster, as shown below.
Enforce the Ingress Policy:
- For ingress policy type, click
your Istio systemto expand the policy folder >> ingress >> rules.rego to see the ingress rules for your Istio 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.
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 Istio proxy as a sidecar container. Click on the Decisions tab to verify all decisions are Allowed for the newly created Istio system.
The Istio system Quick Start links to replace the sample ingress policy. With this ingress policy published, example-app can receive ingress traffic only on the allowed list of endpoint /finance/salary. Switch to 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]
}The above policy lets you allow the ingress connections on endpoint “/finance/salary{user}” in example-app; all other ingress requests are denied.
Validate the Ingress Policy:
Before publishing the policy, see if it’s doing what you want. Click on validate. The Validate button will tell you what percentage of past decisions will be changed by your new policy.
Publish the policy:
Published policies are enforced by OPA as soon as OPA syncs with DAS.
Audit the Decisions:
Modify the Policy and check the decisions:
In the Istio system QuickStart, step #7 modifies the Ingress policy to allow traffic to the path /hr/dashboard
package policy.ingress
default 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"]
}Before you publish the above rule, you want to know its impact. So, first, Validate again to check that the /hr/dashboard denials are now allowed.
Go to your decision logs and check the changes in decisions. See that your new rule would allow ingress requests to host “/hr/dashboard” as well.
Congratulations!
Now, you have learned the following about Istio with OPA and Styra:
Summary:
Added an Istio system in Styra DAS.
Enabled Istio sidecar injection on the default namespace, created envoy filter, OPA config, and deployed Styra Local Plane (SLP) on the machine to integrate with Istio system in Styra DAS.
Finally, we added policies, Enforced, Validated, and published the ingress policies on Styra DAS.
The OPA-Istio integration gives you fine-grained access control over microservice API authorization.
You can use Styra DAS to write policies, distribute policies to OPA, and manage the decisions made by OPA.