Skip to main content
  1. Articles/

Istio Gateway

·
Ro'i Bandel
Author
Ro’i Bandel
Table of Contents

Istio as a Gateway and Ingress Controller

Istio is known for its service mesh capabilities, however it can also serve as a Gateway and Ingress Controller, with support for both Ingress resources and Gateway API resources. Some view this use-case as overkill. However, my own testing of using Istio exclusively as a gateway (without a service mesh) proves that it can in fact work quite well for this purpose. This is strengthened by the benchmarks done by Howard John.

My Rationale for using Istio

Here’s one potential reason I found to use Istio for ingress/gateway instead of Envoy Gateway: Coraza WAF.

I was previously using ingress-nginx which has easy-to-enable support for ModSecurity and OWASP CRS (Core Rule Set). Since ingress-nginx is planned to eventually be replaced with InGate, I decided to look at the currently available Gateway API implementations and what WAF (Web Application Firewall) support they have. I found out that the more modern alternative to ModSecurity is OWASP Coraza WAF. From my research it seems to be able to use Coraza with Envoy Gateway you have to use Tetrate Enterprise Gateway.

However, upon further research I found this OpenShift guide: Creating a Web Application Firewall in Red Hat OpenShift. This guide uses Coraza Proxy WASM with Istio. Istio seems to be required in order to be able to use the WasmPlugin custom resource. I believe that following this guide it should work with Istio on non-OpenShift K8s just the same.

My Installation

I can confirm this works even without OpenShift! I tested this on my Talos staging cluster. Once Istio is installed and configured with the WASM Plugin for OWASP Coraza WAF, test malicious requests get blocked as expected.

The difficult part for me was getting Istio installed and figuring it out how to configure it as a gateway for Ingress and HTTPRoute resources. I wanted to avoid using the more advanced features of Istio (service mesh, ambient mesh etc.), at least for now. I have not used Istio before so there was a learning curve, certainly more complex than ingress-nginx. However, once I got Istio working as a gateway like I wanted, applying the WASM Plugin was relatively straightforward.

This is the solution that I am now using for my “homelab-as-code” Talos cluster.

Istio Gateway Installation

The main resources which I followed are:

  1. Istio / Documentation
  2. Istio / Install with Helm
  3. How to Install and Configure Istio Ingress with Helm
  4. Creating a Web Application Firewall in Red Hat OpenShift

I followed these resources, then adapted them for my own Argo CD GitOps structure and made them work with my existing adyanth/cloudflare-operator and cert-manager deployments. I used some Istio custom resources to make the same Istio Gateway work with both Ingress resources and Gateway API resources. This essentially made Istio a drop-in replacement for my previous ingress-nginx deployment (any existing Ingress resources now use Istio as the default ingress class), with the added ability to now use Gateway API.

Benchmarks

Howard John works on Istio, so is not entirely without bias (which he admits). Nevertheless, he has created Gateway API Benchmarks, a common set of tests to evaluate a Gateway API implementation. Istio comes out quite favorably in the benchmark ("✅ No issues were found"): howardjohn/gateway-api-bench: Gateway API Benchmarks provides a common set of tests to evaluate a Gateway API implementation.

UPDATE: John Howard has released Gateway API Benchmarks - Part 2. According to the new benchmarks, Istio is still among the leading Gateway API implementations; however, the new Agentgateway has better performance in the Route Scale and ListenerSet Scale benchmarks.

Featured image by Sam Moghadam on Unsplash.

Related

Docker User Interfaces

·
There are different User Interfaces that help use Docker.

KYAML

·
Today I learned, in Kubernetes v1.34, kubectl will also support a new strict subset of YAML called KYAML.