<?xml version="1.0" encoding="utf-8" standalone="yes"?><feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en"><script src="https://www.rss.style/js/atom-style.js" xmlns="http://www.w3.org/1999/xhtml"/><title>Tower of Kubes</title><link rel="self" type="application/atom+xml" hreflang="en" href="https://www.towerofkubes.com/tags/gateway/feed.xml"/><link rel="alternate" type="text/html" hreflang="en" href="https://www.towerofkubes.com/tags/gateway/"/><link rel="alternate" type="application/rss+xml" hreflang="en" href="https://www.towerofkubes.com/tags/gateway/index.xml"/><id>/</id><updated>2025-10-19T00:00:00Z</updated><author><name>Ro'i Bandel</name></author><generator>Hugo 0.157.0</generator><entry><title>Istio Gateway</title><link rel="alternate" type="text/html" hreflang="en" href="https://www.towerofkubes.com/articles/istio-gateway/"/><id>https://www.towerofkubes.com/articles/istio-gateway/</id><updated>2025-10-19T00:00:00Z</updated><summary type="html">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.</summary><content type="html"><![CDATA[
<h2 class="relative group">Istio as a Gateway and Ingress Controller
    <div id="istio-as-a-gateway-and-ingress-controller" class="anchor"></div>
    
</h2>
<p>Istio is known for its service mesh capabilities, however it can also serve as a Gateway and Ingress Controller, with support for both <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource"  target="_blank" rel="noreferrer">Ingress resources</a> and <a href="https://kubernetes.io/docs/concepts/services-networking/gateway/#resource-model"  target="_blank" rel="noreferrer">Gateway API resources</a>. Some view this use-case as <a href="https://www.reddit.com/r/kubernetes/comments/1m1frpy/what_are_the_advantages_of_using_istio_over_nginx/"  target="_blank" rel="noreferrer">overkill</a>. 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 <a href="https://blog.howardjohn.info/"  target="_blank" rel="noreferrer">Howard John</a>.</p>

<h2 class="relative group">My Rationale for using Istio
    <div id="my-rationale-for-using-istio" class="anchor"></div>
    
</h2>
<p>Here’s one potential reason I found to use Istio for ingress/gateway instead of Envoy Gateway: Coraza WAF.</p>
<p>I was previously using <a href="https://kubernetes.github.io/ingress-nginx/"  target="_blank" rel="noreferrer">ingress-nginx</a> which has easy-to-enable <a href="https://kubernetes.github.io/ingress-nginx/user-guide/third-party-addons/modsecurity/"  target="_blank" rel="noreferrer">support for ModSecurity</a> and OWASP CRS (Core Rule Set). Since <a href="https://kubernetes.github.io/ingress-nginx/"  target="_blank" rel="noreferrer">ingress-nginx</a> is planned to eventually be replaced with <a href="https://github.com/kubernetes-sigs/ingate"  target="_blank" rel="noreferrer">InGate</a>, 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 <a href="https://coraza.io/"  target="_blank" rel="noreferrer">OWASP Coraza WAF</a>. From my research it seems to be able to use Coraza with Envoy Gateway you have to use Tetrate Enterprise Gateway.</p>
<p>However, upon further research I found this OpenShift guide: <a href="https://www.redhat.com/en/blog/creating-web-application-firewall-red-hat-openshift"  target="_blank" rel="noreferrer">Creating a Web Application Firewall in Red Hat OpenShift</a>. This guide uses <a href="https://github.com/corazawaf/coraza-proxy-wasm"  target="_blank" rel="noreferrer">Coraza Proxy WASM</a> with Istio. Istio seems to be required in order to be able to use the <a href="https://istio.io/latest/docs/reference/config/proxy_extensions/wasm-plugin/"  target="_blank" rel="noreferrer">WasmPlugin custom resource</a>. I believe that following this guide it should work with Istio on non-OpenShift K8s just the same.</p>

<h2 class="relative group">My Installation
    <div id="my-installation" class="anchor"></div>
    
</h2>
<p>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.</p>
<p>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.</p>
<p>This is the solution that I am now using for my “homelab-as-code” Talos cluster.</p>

<h2 class="relative group">Istio Gateway Installation
    <div id="istio-gateway-installation" class="anchor"></div>
    
</h2>
<p><strong>The main resources which I followed are:</strong></p>
<ol>
<li><a href="https://istio.io/latest/docs/"  target="_blank" rel="noreferrer">Istio / Documentation</a></li>
<li><a href="https://istio.io/latest/docs/setup/install/helm/"  target="_blank" rel="noreferrer">Istio / Install with Helm</a></li>
<li><a href="https://tetrate.io/blog/istio-ingressclass-controller-with-helm"  target="_blank" rel="noreferrer">How to Install and Configure Istio Ingress with Helm</a></li>
<li><a href="https://www.redhat.com/en/blog/creating-web-application-firewall-red-hat-openshift"  target="_blank" rel="noreferrer">Creating a Web Application Firewall in Red Hat OpenShift</a></li>
</ol>
<p>I followed these resources, then adapted them for my own Argo CD GitOps structure and made them work with my existing <a href="https://github.com/adyanth/cloudflare-operator"  target="_blank" rel="noreferrer">adyanth/cloudflare-operator</a> and <a href="https://cert-manager.io/"  target="_blank" rel="noreferrer">cert-manager</a> deployments. I used some Istio custom resources to make the same Istio Gateway work with both <a href="https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource"  target="_blank" rel="noreferrer">Ingress resources</a> and <a href="https://kubernetes.io/docs/concepts/services-networking/gateway/#resource-model"  target="_blank" rel="noreferrer">Gateway API resources</a>. 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.</p>

<h2 class="relative group">Benchmarks
    <div id="benchmarks" class="anchor"></div>
    
</h2>
<p><a href="https://blog.howardjohn.info/"  target="_blank" rel="noreferrer">Howard John</a> works on Istio, so is not entirely without bias (which he admits). Nevertheless, he has created <a href="https://github.com/howardjohn/gateway-api-bench"  target="_blank" rel="noreferrer">Gateway API Benchmarks</a>, a common set of tests to evaluate a Gateway API implementation. Istio comes out quite favorably in the benchmark ("✅ No issues were found"): <a href="https://github.com/howardjohn/gateway-api-bench"  target="_blank" rel="noreferrer">howardjohn/gateway-api-bench: Gateway API Benchmarks provides a common set of tests to evaluate a Gateway API implementation</a>.</p>

    <div class="admonition tip">
      <div class="admonition-header"><svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 384 512"><path d="M272 384c9.6-31.9 29.5-59.1 49.2-86.2c0 0 0 0 0 0c5.2-7.1 10.4-14.2 15.4-21.4c19.8-28.5 31.4-63 31.4-100.3C368 78.8 289.2 0 192 0S16 78.8 16 176c0 37.3 11.6 71.9 31.4 100.3c5 7.2 10.2 14.3 15.4 21.4c0 0 0 0 0 0c19.8 27.1 39.7 54.4 49.2 86.2l160 0zM192 512c44.2 0 80-35.8 80-80l0-16-160 0 0 16c0 44.2 35.8 80 80 80zM112 176c0 8.8-7.2 16-16 16s-16-7.2-16-16c0-61.9 50.1-112 112-112c8.8 0 16 7.2 16 16s-7.2 16-16 16c-44.2 0-80 35.8-80 80z"/></svg>
        <span><strong>UPDATE:</strong> John Howard has released <a href="https://github.com/howardjohn/gateway-api-bench/blob/main/README-v2.md"  target="_blank" rel="noreferrer">Gateway API Benchmarks - Part 2</a>. According to the new benchmarks, Istio is still among the leading Gateway API implementations; however, the new Agentgateway has better performance in the <a href="https://github.com/howardjohn/gateway-api-bench/blob/main/README-v2.md#route-scale"  target="_blank" rel="noreferrer">Route Scale</a> and <a href="https://github.com/howardjohn/gateway-api-bench/blob/main/README-v2.md#listenerset-scale"  target="_blank" rel="noreferrer">ListenerSet Scale</a> benchmarks.</span>
      </div>
    </div><hr>
<p><em>Featured image by <a href="https://unsplash.com/@sammoghadam?utm_source=hugo&utm_medium=referral"  target="_blank" rel="noreferrer">Sam Moghadam</a> on <a href="https://unsplash.com/?utm_source=hugo&utm_medium=referral"  target="_blank" rel="noreferrer">Unsplash</a>.</em></p>
]]></content><author><name>Ro'i Bandel</name></author><category term="istio" label="Istio" scheme="https://www.towerofkubes.com/tags/istio/"/><category term="gateway" label="Gateway" scheme="https://www.towerofkubes.com/tags/gateway/"/><category term="ingress" label="Ingress" scheme="https://www.towerofkubes.com/tags/ingress/"/><category term="homelab" label="Homelab" scheme="https://www.towerofkubes.com/tags/homelab/"/><category term="k8s" label="K8s" scheme="https://www.towerofkubes.com/tags/k8s/"/><published>2025-10-19T00:00:00Z</published></entry></feed>