Istio is an open source service mesh for managing the different microservices that make up a cloud-native application. Istio provides a mechanism to customize the Envoy configuration generated by Istio Pilot using .
This tutorial shows how Istio’s EnvoyFilter can be configured to include Envoy’s External Authorization filter to delegate authorization decisions to OPA.
This tutorial requires Kubernetes 1.14 or later. To run the tutorial locally, we recommend using in version v1.0+
with Kubernetes 1.14+.
The tutorial also requires Istio v1.8.0 or later. It assumes you have Istio deployed on top of Kubernetes. See Istio’s Quick Start page to get started.
The quick_start.yaml
manifest defines the following resources:
Kubernetes namespace (
opa-istio
) for OPA-Envoy control plane components.Kubernetes admission controller in the
opa-istio
namespace that automatically injects the OPA-Envoy sidecar into pods in namespaces labelled withopa-istio-injection=enabled
.OPA configuration file and an OPA policy into ConfigMaps in the namespace where the app will be deployed, e.g.,
default
. The following is the example OPA policy:- alice is granted a guest role and can perform a
GET
request to/productpage
. - bob is granted an admin role and can perform a
GET
to/productpage
and/api/v1/products
.
- alice is granted a guest role and can perform a
```
package istio.authz
import input.attributes.request.http as http_request
import input.parsed_path
default allow = false
allow {
parsed_path[0] == "health"
http_request.method == "GET"
}
allow {
roles_for_user[r]
required_roles[r]
}
roles_for_user[r] {
r := user_roles[user_name][_]
}
required_roles[r] {
perm.method = http_request.method
}
user_name = parsed {
[_, encoded] := split(http_request.headers.authorization, " ")
[parsed, _] := split(base64url.decode(encoded), ":")
}
user_roles = {
"alice": ["guest"],
"bob": ["admin"]
}
role_perms = {
"guest": [
{"method": "GET", "path": "/productpage"},
],
"admin": [
{"method": "GET", "path": "/productpage"},
{"method": "GET", "path": "/api/v1/products"},
],
}
```
OPA is configured to query for the `data.istio.authz.allow` decision. If the response is `true` the operation is allowed, otherwise the operation is denied. Sample input received by OPA is shown below:

```
data.istio.authz.allow
```

```
"attributes": {
"request": {
"http": {
"path": "/productpage",
"headers": {
"authorization": "Basic YWxpY2U6cGFzc3dvcmQ="
}
}
}
}
}
```
With the input value above, the answer is:

```
true
```
An example of the complete input received by OPA can be seen [here](https://github.com/open-policy-agent/opa-envoy-plugin/tree/master/examples/istio#example-input).
> In typical deployments the policy would either be built into the OPA container image or it would fetched dynamically via the [Bundle API](https://www.openpolicyagent.org/docs/latest/bundles/). ConfigMaps are used in this tutorial for test purposes.
kubectl label namespace default opa-istio-injection="enabled"
kubectl label namespace default istio-injection="enabled"
kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/bookinfo/networking/bookinfo-gateway.yaml
minikube:
export INGRESS_PORT=$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.spec.ports[?(@.name=="http2")].nodePort}')
export INGRESS_HOST=$(minikube ip)
export GATEWAY_URL=$INGRESS_HOST:$INGRESS_PORT
echo $GATEWAY_URL
minikube (example):
Check that alice can access /productpage
BUT NOT /api/v1/products
.
curl --user alice:password -i http://$GATEWAY_URL/productpage
curl --user alice:password -i http://$GATEWAY_URL/api/v1/products
Check that bob can access /productpage
AND /api/v1/products
.
curl --user bob:password -i http://$GATEWAY_URL/productpage
curl --user bob:password -i http://$GATEWAY_URL/api/v1/products
Congratulations for finishing the tutorial !
This tutorial showed how Istio’s can be configured to use OPA as an External authorization service.
This tutorial also showed a sample OPA policy that returns a decision to indicate whether a request should be allowed or not.