Alek's Blog - service-mesh

Blocking AI Crawlers on Istio: AuthorizationPolicy's Ceiling and Envoy's Full-String Regex Trap

aleks — Mon, 27 Jul 2026 00:00:00 +0000

Blocking a list of known AI-crawler user agents at an ingress gateway sounds like a five-minute job: match the User-Agent</code> header against a list of bot names, return 403</code>. The obvious tool for that on Istio</a> is its own AuthorizationPolicy</code> CRD — until you actually try to express “header contains one of these ~160 substrings” in it, and discover the API simply cannot say that. The next obvious fallback — a Lua filter that runs the match by hand — works, but is more machinery than the problem needs. There is a third option: configure the same native Envoy filter Istio’s own CRD compiles down to, directly, with the one matching primitive the CRD never exposes. Getting there also surfaces a second, unrelated gotcha in how Envoy’s regex matching actually works, which would have made an obvious “just use one big regex” approach fail silently.</p>



Istio AuthorizationPolicy & HTTP/2 Coalescing
aleks — Mon, 13 Jul 2026 00:00:00 +0000
Isolating an admin surface behind its own hostname and an IP-restricted
Istio</a> AuthorizationPolicy</code> sounds like a Tuesday-afternoon change: add a
second HTTPRoute</code>, add a DENY</code> policy with an allowlist, done. Two non-obvious Envoy behaviors
turned it into a two-day debugging exercise instead — one in how AuthorizationPolicy</code> resolves
“the client’s IP,” and one in how browsers reuse HTTP/2 connections across hostnames that share a
certificate. Neither is specific to Keycloak or to this particular setup; both apply to any Istio
or Envoy Gateway API ingress sitting behind a cloud load balancer with a shared wildcard
certificate.</p>
This post walks through both bugs, how they were root-caused, and the fix for each — so the next
person hitting either symptom can skip straight to the cause.</p>


Istio vs. Linkerd: Service Mesh on Kubernetes
aleks — Tue, 12 May 2026 00:00:00 +0000
Both Istio</a> and Linkerd</a> are CNCF Graduated service
meshes that provide automatic mTLS, traffic policy, and observability for Kubernetes
workloads. Both run in sidecar mode for this comparison — a proxy container injected into
every pod. The fundamental difference is the data plane: Istio uses
Envoy</a>, Linkerd uses its own Rust-based proxy
(linkerd2-proxy</code></a>). That choice drives the differences in overhead, extensibility, and egress
control.</p>
This post compares them on the dimensions that matter for a production deployment. For the
broader question of Istio vs. Envoy Gateway (ingress-only), ambient mode, and managed cloud
specifics (AKS, GKE, OVH MKS), see the companion post
Istio vs. Envoy Gateway: Gateway API on Kubernetes</a>.</p>


Istio vs. Envoy Gateway: Gateway API on Kubernetes
aleks — Thu, 30 Apr 2026 00:00:00 +0000
Both Istio</a> and Envoy Gateway</a> implement the
Kubernetes Gateway API</a> and use Envoy as their data plane.
That is roughly where the similarity ends. Istio is a full service mesh that happens to
implement Gateway API; Envoy Gateway is a dedicated Gateway API controller with no mesh
ambitions. Choosing between them is mostly a question of scope.</p>
This post starts with that comparison — architecture, mTLS, egress control, and resource
overhead — then broadens to cover Cilium</a> as a lighter alternative for
East-West security, how the choice plays out on managed Kubernetes offerings (AKS, GKE, and
OVH MKS including their cloud-native ingress and egress options), and finally how to get
the real client IP through a cloud load balancer to your application.</p>