Using the Azure Application gateway WAF with Istio-1

Purpose

When I was working on my last post on Traffic management using Istio 101, one thing which came into my mind was “Can you leverage Azure Application Gateway WAF (or GCP Armor in GCP) and other security features while not giving up on Istio service mesh features at the same time?”

Istio documentation states that “They can be deployed in front of the Istio ingress gateway to normalize requests entering the mesh.”, so I thought of giving it a go by testing.

You can’t use the Istio Ingress gateway when using the Azure application gateway ingress controller. It can exist but the traffic won’t be routed through the Istio Ingress gateway. But you can still leverage the other Istio service mesh features not related to the Istio Ingress gateway.

Test Environment Setup

• Create an AKS cluster using documentation.
• Connect to AKS cluster using instructions from the portal

fig1

• Run the below shell script to set up istiod. You can skip the last 3 commands which setup Istio Ingress Standalone Envoy proxy as you won’t be using Istio Ingress Gateway

• Run the below script to deploy the BookInfo app (provided by Istio for Demo purposes).

• Create an Ingress resource for the application.

kubectl apply -f bookinfo-agic.yaml -n appbi

Observer that annotation “kubernetes.io/ingress.class: azure/application-gateway” is set to configure the ingress controller as Application Gateway Ingress controller.

AGIC is configured via the Kubernetes Ingress resource, along with Service and Deployments/Pods. AGIC continuously watches the service endpoints for the services configured in the Ingress resource and runs ARM templates to update the Application Gateway configuration if there is an update.

Application Gateway talks to pods using their private IP directly and does not require NodePort or KubeProxy services. This also brings better performance to your deployments.

• Follow the documentation to enable AGIC for the AKS cluster you created. Once the integration is successful, you can review the logs of the ingress controller to see if the Application Gateway is updated with the configuration.

kubectl logs deployment/ingress-appgw-deployment -n kube-system -f

Also, review the Application gateway instance’s configuration from the Azure portal.

Enable WAF if not enabled already.

Configure the Istio-specific resources

You will configure Virtual Service and Destination rule resources for “reviews” application as it has 3 different versions and you can test if Istio Envoy proxy is taking over when the request enters the service mesh. For application-related details refer to my older post.

• Configure virtual service for “reviews” application

kubectl apply -f vs-reviews.yaml -n appbi

This will create a new virtual service “reviews”.

• Configure destination rule for “reviews” application

kubectl apply -f dr-reviews.yaml -n appbi

This will create a new destination rule “reviews”.

The Test

• Get the Public IP of the Application gateway and add it to the hosts file on your client machine as “bookinfo.app.io”. Observe that the Book Reviews section displays different “Book reviews” UI i.e v1 one without stars, v2 one with black stars, and v3 one with red stars. Review often which UI is displayed when you refresh the app page.
• You can add fault injections (refer to my older post to learn about that) and see how that affects the application.

Ingress request flow

The below diagram shows how the traffic flows from the client to the pods via the application gateway and service mesh serving the web application.

Fig2

Observe that the traffic directly reaches the endpoint pod of productpage app and service mesh comes into the picture when the pod related to productpage app tries to reach the other services.

Results

• Using Application Gateway (AGIC) with WAF with Istio service mesh is a valid configuration.
• You can leverage the most benefits of both worlds with this configuration.
• This test is on a very simple application, results may differ for a complex application.

Limitations

• You are deprived of the features that you get when the traffic enters through the Istio Ingress Gateway.
• Traffic hits the pods directly at first access, service mesh is utilized only for internal communication between pods.

Please read my next article in which I am trying another configuration where you will learn how to get rid of one of the above limitations