5 Steps To Combine Istio With OPA – DZone – Uplaza

Authentication and Authorization are huge elements of the safety puzzle that have to be solved by cloud architects and DevOps engineers. On this weblog, we’ll particularly take a look at obtain authorization/entry management; i.e., what actions the authenticated entity can carry out within the Istio service mesh. It helps to safe the infrastructure by stopping actions with malicious intent.

Authorization in a service mesh could be outlined utilizing OPA insurance policies. OPA is a mechanism that helps DevOps of us outline and implement authorization insurance policies for Kubernetes workloads. On this piece, we’ll see:

• What OPA is
• Why it is best to combine OPA with Istio service mesh
• How Istio and OPA authorize requests
• The precise steps you possibly can comply with to combine OPA with Istio

What Is OPA?

OPA (brief for “Open Coverage Agent”) is an open-source, general-purpose policy enforcement engine that lets DevOps define policy as code using a high-level declarative language called Rego. OPA helps centrally outline and implement insurance policies throughout the stack whereas relieving builders from writing authorization insurance policies into the applying code. Right here is how OPA works (check with Determine 1):

1. The applying/service receives a request.
2. The service sends a JSON authorization request to OPA.
3. OPA checks the request in opposition to the outlined authorization insurance policies.
4. OPA takes the choice and returns the authorization response (ALLOW/DENY) to the service in JSON format.

Determine 1: Authorization request move with OPA

Be aware that it doesn’t have to be an software written by a developer that’s sending the authorization request: it may be Argo CD, Kubernetes Gateway API useful resource, Terraform, Prometheus, or the rest since OPA is general-purpose. (I’ve talked about and drawn an software in a Kubernetes cluster right here for the sake of comfort and higher understanding.)

Why Combine OPA With Istio?

Istio has a strong authorization mechanism. Nonetheless, having a devoted coverage enforcement engine like OPA alongside Istio service mesh has its personal advantages:

• Centralized administration system to outline and implement insurance policies: OPA makes it simpler for DevOps to centrally handle authorization insurance policies for your entire stack. This consists of meshed workloads, non-meshed stack, and likewise authorization checks (a coverage that forestalls deployment on Fridays, for instance). 
• Extra flexibility and granularity in defining insurance policies: In the event you take a look at the desk beneath (Determine 2), it’s clear that Istio authorization can do so much and match a request based mostly on quite a lot of fields from totally different knowledge sources. Nonetheless, Istio AuthorizationPolicy CRD could be restricted in configuring the HTTP request physique or any contextual knowledge within the fields, for which OPA can be utilized. In contrast to Istio, OPA can use any knowledge for coverage analysis.
• Simplified AuthZ configuration: It may be tedious for DevOps to configure complicated authorization guidelines in Istio. OPA is configured utilizing Rego, which is nearer to a programming language. It’s comparatively simpler to set fundamental to complicated coverage guidelines utilizing Rego.

Determine 2: Tabular comparability between Istio and OPA authorization (supply)

How Istio and OPA Authorize Requests

DevOps can deploy OPA as a separate service altogether or as a sidecar container alongside the Envoy proxy and the applying container in a pod. The sidecar container method is healthier to cut back latency.

OPA sidecar containers have to be injected into the applying pod similar to Istio’s Envoy proxy sidecar containers. We will arrange the injected OPA containers to mount ConfigMaps that include the authorization guidelines; each OPA sidecar container within the namespace will then mount the identical configuration and AuthZ guidelines outlined within the ConfigMap.

As soon as the OPA sidecar is injected, the Envoy proxy will ship authorization requests to OPA to make authorization choices when the service receives a request:

Determine 3: Istio-OPA authorization workflow

Suppose DevOps of us don’t need each injected OPA container in the identical namespace to comply with the identical configurations and need to implement totally different guidelines. In that case, they should do any of the next:

• Take away onerous coding which lets the present injection coverage use a selected ConfigMap
• Configure mutating webhook and disable sidecar injection on the pod-level
• Serve up coverage bundles from a distant HTTP server
• Deploy the applying and the sidecars in a unique namespace with totally different ConfigMap

Steps To Combine Opa With Istio: Demo

The concept right here is to make OPA the exterior authorizer as an alternative of Envoy proxy sidecars — to make entry management choices.

I’ll use the traditional Bookinfo software from Istio documentation for the demo. I’ll configure OPA with Istio for entry management and examine whether or not it’s enforced by firing requests to bookinfo/productpage:

Determine 4: Istio-OPA integration tutorial diagram

Be aware that /productpage is the UI, which makes inner calls to different providers, similar to critiques and scores providers (diagram). I’ll inject OPA into each pod within the bookinfo namespace; all OPA containers mount the identical ConfigMap and have the identical authorization insurance policies due to that. The default habits of the Bookinfo software doesn’t ahead any HTTP authentication so the inner calls will fail authentication and thus authorization.

We are going to comply with the given steps so as:

1. Configure OPA sidecar injection
2. Allow communication between Istio proxy and OPA
3. Deploy OPA configuration
4. Apply Istio configuration
5. Deploy the applying and check the Istio-OPA authorization setup

The prerequisite for the demo is to have Istio v1.19+ put in in your cluster. I’m utilizing Istio v1.21.0 right here.

OPA supplies a quickstart.yaml for simple set up. I’ve break up the yaml into three for simpler understanding: IMESH GitHub repo. 

Step 1: Configure OPA Sidecar Injection

Apply the opa_controller.yaml:

kubectl apply -f opa_controller.yaml

The opa_controller.yaml deploys every little thing — TLS certificates, ConfigMap containing injection coverage, admission controller deployment, and mutating webhook configuration — into the opa-istio namespace (check with Determine 5):

1. The mutating webhook controller (opa-istio-admission-controller) will then pay attention for a selected label (opa-istio-injection) with the worth set to enabled.
2. The webhook controller calls the admission-controller, which has the injection coverage.
3. The injection coverage tells the admission-controller inject the OPA sidecar container into the pod.

Determine 5: OPA sidecar injection configuration

Now, earlier than deploying the Bookinfo software, we’ll create bookinfo namespace and comply with the remainder of the steps:

Create the bookinfo namespace by making use of bookinfo-ns.yaml: 

kubectl apply -f bookinfo-ns.yaml

You’ll be able to see the namespace has the label opa-istio-injection: enabled, to auto-inject OPA sidecars.

Step 2: Allow Communication Between Istio Proxy and OPA

Edit Istio ConfigMap within the istio-system namespace and add extensionProviders (opa-ext-authz-grpc), in order that it permits exterior authorization within the mesh:

• Copy extensionProviders from the remark in opa_controller.yaml.
• Edit Istio ConfigMap and add extensionProviders within the mesh discipline.
• Make sure the indentation is appropriate.
• Save the config.

The step makes it attainable for istio-proxy to speak to opa-istio container within the pod for authorization requests.

In the event you take a look at the extensionProviders, it’s an ExtAuthzGrpc filter sort in Envoy with a specified service entry and port:

...

extensionProviders:
- title: opa-ext-authz-grpc
envoyExtAuthzGrpc:
service: opa-ext-authz-grpc.native
       port: "9191"

...

The extensionProviders’ title, service deal with, and port ought to be the identical within the opa_authz.yaml and opa_config.yaml.

Step 3: Deploy OPA Configuration

The opa_config.yaml defines open policy-related configurations. It has opa-istio-config and opa-policy ConfigMaps — which outline the gRPC service implementation (envoy_ext_authz_grpc) and the precise authorization insurance policies, respectively.

The authorization insurance policies could be divided into two elements: the primary half defines the circumstances beneath which the authorization is allowed or denied; the second half defines the person roles and the permissions for every function.

The authorization insurance policies may take a while to get used to, as Rego doesn’t use many key phrases right here. Allow a more moderen model of Rego to get key phrases (permit if situation key phrase, for instance).

Apply OPA configuration within the bookinfo namespace, because it goes together with the applying:

kubectl apply -f opa_config.yaml -n bookinfo

Step 4: Apply Istio Configuration

The opa_authz.yaml file comprises Istio configurations. It has an AuthorizationPolicy and a ServiceEntry. Be aware that the Authorization Coverage supplier is opa-ext-authz-grpc, which is the extensionProvider we configured within the ConfigMap in step 2. 

Equally, the hostname outlined within the ServiceEntry is identical because the service deal with given within the extensionProvider (opa-ext-authz-grpc.native). The gRPC service will run on port 9191 at localhost 127.0.0.1, which the ServiceEntry makes opa-istio sidecars accessible throughout the pod by the istio-proxy container.

Deploy the configuration:

kubectl apply -f opa_authz.yaml -n bookinfo

Step 5: Deploy the Software and Check the Istio-OPA Authorization Setup

Deploy the Bookinfo software and the gateway:

kubectl apply -f /your_Istio_directory/samples/bookinfo/platform/kube/bookinfo.yaml -n bookinfo
kubectl apply -f /your_Istio_directory/samples/bookinfo/networking/bookinfo-gateway.yaml -n bookinfo

Verify the pods within the bookinfo namespace:

kubectl get pods -n bookinfo

You’ll be able to see that every pod has 3 containers operating in them: the applying, Envoy proxy (istio-proxy), and OPA (opa-istio) containers.

Get the IP of the Istio gateway to entry the service:

kubectl get svc -n istio-system

Now every little thing is about, and we’re prepared to check the authorization insurance policies. The insurance policies we outlined in opa_config.yaml are the next:

...

user_roles = {
"alice": ["guest"],
"bob": ["admin"]
}

role_perms = {
"guest": [
{"method": "GET", "path": "/productpage"},
],
"admin": [
{"method": "GET", "path": "/productpage"},
{"method": "GET", "path": "/api/v1/products"},
        ],

...

Alice is a visitor person who can solely entry the /productpage; Bob is an admin who can entry the paths /productpage and /api/v1/merchandise. Allow us to confirm the insurance policies.

Making an attempt to entry /api/v1/merchandise from Alice:

curl -vvv your_istio_gateway_ip/api/v1/merchandise -u alice:password

You’ll be able to see that 403 Forbidden response since Alice doesn’t have entry to the trail. Allow us to attempt the identical path as Bob:

curl -vvv your_istio_gateway_ip/api/v1/merchandise -u bob:password

It reveals the HTTP standing 200 OK and the web page content material in direction of the top of the response.

Instance State of affairs for Entry Management With OPA

You should use Istio’s AuthorizationPolicy CRD to implement the coverage proven within the demo above. You do not want OPA. Nonetheless, there are situations the place Istio authorization could be restricted, as talked about within the desk at first. Let me give a easy instance.

Suppose there’s a BookReviews software which is a GraphQL service, the place reviewers submit critiques, editors edit and publish these critiques, and customers learn the printed critiques.

When a reviewer provides a guide evaluation to the service, the request would come with the reviewer’s JWT, containing the teams and roles (reviewer or editor) the reviewer belongs to. The request physique would additionally include a GraphQL mutation question with the newly created evaluation knowledge.

Allow us to say you need to guarantee the next circumstances:

• Solely reviewers can submit critiques.
• An editor can solely edit a evaluation whether it is written by a reviewer belonging to the identical group managed by them.
• Solely editors can mark a evaluation as “ready to publish”.

Right here is the diagram that features the above insurance policies:

Istio’s AuthorizationPolicy will battle to implement the above circumstances. The reason being that Istio can’t use the GraphQL request physique for authorization checks, which is a JSON object alongside the JWT wanted for coverage analysis.

OPA doesn’t have such limitations. It might load any knowledge for coverage checks, and DevOps can write these guidelines in a extra ergonomic method utilizing Rego.

Video: Demo in Motion

In the event you desire to look at the demo in motion, please examine the video beneath:S

Enterprise Help for Integrating Istio

Most enterprises use OPA to outline and implement authorization insurance policies for his or her complete stack. Having a central mechanism for entry management improves the general safety and agility of IT groups. In any other case, builders will waste time creating authorization insurance policies into their software code written in a selected language, which impedes scalability and quicker enterprise logic rollout.