Application routing add on Gateway API implementation Limitation Query

Question

Application routing add on Gateway API implementation Limitation Query

Laha, Prithwish 25

I am exploring Application routing add on Gateway API implementation for AKS ingress solution. I want to implement end to end TLS on traffic (Client <-> Gateway API <-> k8s backend service/Application Pods). The documentation states below limitation. I want to understand what does it exactly mean. Does it not support TLS between Gateway API/Ingress and k8s backend service/Application Pods ?

"Configuring HTTPS ingress access to HTTPS services – i.e., Server Name Indication (SNI) Passthrough – via the TLSRoute resource is not currently supported. Support for the TLSRoute resource will be available once AKS adds support for Istio 1.30, at which point your application routing Istio control plane will be automatically upgraded to that version."

Nikhil Duserla 9,940 Reputation points Microsoft External Staff Moderator

2026-06-29T15:49:05.7733333+00:00
Hey! Great question—let’s unpack that limitation text in plain terms.

What that limitation means

In the application routing add-on Gateway API implementation, AKS uses an Istio-based control plane to configure ingress behavior.

The limitation says:

“Configuring HTTPS ingress access to HTTPS services – i.e., SNI Passthrough – via the TLSRoute resource is not currently supported…”

Interpreting it for your end-to-end TLS goal

Your desired traffic flow is:

Client ⇄ Gateway API (Ingress/Gateway proxy) ⇄ Kubernetes Service/Pods

Microsoft’s limitation is not saying that TLS between the gateway/proxy and your pods is impossible in general.

Instead, it’s specifically about this Gateway API feature path:

Using TLSRoute to request SNI passthrough behavior

Where the gateway effectively does not terminate TLS in a way that lets the backend perform its own TLS handshake based on SNI

So, with the current limitation:

You can still terminate TLS at the gateway (HTTPS from client to gateway).

But you can’t use TLSRoute SNI Passthrough to forward TLS through the gateway to HTTPS backends in the way TLSRoute is designed for.

The doc even clarifies when this changes:

Support for TLSRoute is expected once AKS adds support for Istio 1.30, and then the add-on’s Istio control plane will be upgraded automatically.

Direct answer to your question

“Does it not support TLS between Gateway API/Ingress and k8s backend service/Application Pods?”

Based on the wording of the limitation, the issue is specifically:

TLS passthrough / TLSRoute SNI Passthrough to reach HTTPS services

It does not read as “TLS to pods is unsupported at all,” but as “the particular TLSRoute + SNI Passthrough configuration is not supported yet.”

So if your goal is end-to-end encryption where the gateway still terminates TLS, that’s typically different from SNI passthrough and may still be achievable (depending on the exact TLS mode/resources you’re planning to use). But if your goal is specifically TLSRoute-based passthrough, then the doc says that path is currently not supported.

Follow-up questions (to pinpoint the exact TLS pattern you want)

Are you aiming for TLS termination at the Gateway/Ingress (gateway presents cert to client), or do you specifically need TLS passthrough so the pods terminate TLS?

Which resources are you planning to use for the backend TLS behavior—are you planning to use TLSRoute explicitly, or just Gateway with TLS settings?

What’s your backend protocol expectation: HTTPS with standard certs at the pods, or something else (mTLS, custom CA chain, etc.)?

Are you using the application routing Gateway API implementation (Gateways with GatewayClass like approuting-istio)?

If you share your intended Gateway/TLSRoute snippets (redact any hostnames/certs), I can help you map whether your desired flow falls into “supported TLS termination” vs “unsupported TLSRoute SNI passthrough.”

References (from provided documentation)

AKS Application routing add-on – Limitations (includes TLSRoute / SNI passthrough not supported): https://learn.microsoft.com/azure/aks/app-routing-gateway-api?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#limitations

AKS Application routing add-on – Overview / Gateway API via add-on (context that it deploys an Istio control plane): https://learn.microsoft.com/azure/aks/app-routing-gateway-api?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider

AKS application routing add-on – Configure ingress examples (Gateway/TLS workflow references): https://learn.microsoft.com/azure/aks/app-routing-gateway-api?wt.mc_id=knowledgesearch_inproduct_azure-cxp-community-insider#configure-ingress-using-a-kubernetes-gateway

Note: This content was drafted with the help of an AI system. Please verify the information before relying on it for decision-making.

1 answer

Your answer

Answer 1

Alex Burlachenko 23,575 MVP Volunteer Moderator

Hi Laha Prithwish, thx for sharing urs issue here at Q&A portal.

That limitation is about SNI passthrough using TLSRoute, not all backend TLS. It means AKS application routing currently doesn’t support passing the original client TLS session straight through the Gateway to an HTTPS backend using Gateway API TLSRoute. So this is not supported right now Client TLS > Gateway just passes SNI/TLS through > backend pod terminates TLS

But u can still usually do TLS termination at the Gateway and then connect to backend services depending on what the addon supports for the HTTPRoute/backend config.

So the difference is Client > HTTPS > Gateway terminates TLS > HTTP/HTTPS to backend

vs

Client > HTTPS passthrough > backend terminates TLS

The doc is saying the second one, SNI passthrough with TLSRoute, isn’t supported until AKS supports the needed Istio version. https://learn.microsoft.com/en-us/azure/aks/app-routing-gateway-api & https://gateway-api.sigs.k8s.io/api-types/tlsroute/ & https://istio.io/latest/docs/tasks/traffic-management/ingress/secure-ingress/

If u need strict end-to-end TLS where the pod owns the cert and decrypts traffic itself, this addon may not fit yet. U may need Istio ingress directly, NGINX ingress with SSL passthrough, or another ingress/gateway option that supports TLS passthrough today.

Rgds,

Alex

&

If my answer was helpful pls mark it and additional thx if u follow me at Q&A portal

and at my blog https://ctrlaltdel.blog/

Laha, Prithwish 25 Reputation points

2026-06-30T13:14:24.6466667+00:00

@Alex Burlachenko Thank you for the response. In my case, backend pods will contain its own certificate. I came across BackendTLSPolicy Gateway API resource to configure TLS in order to convey HTTPS from the Gateway dataplane to the backend. Will it fit with Application routing add on Gateway API implementation ?
Alex Burlachenko 23,575 Reputation points MVP Volunteer Moderator

2026-06-30T13:47:32.37+00:00

Thx for the follow-up. BackendTLSPolicy is definitely the right resource to look at if your goal is TLS from the Gateway to the backend service, where the backend pods present their own certificates.

However, I'd verify whether the AKS Application Routing add-on actually implements BackendTLSPolicy. The Gateway API specification defines it, but individual Gateway implementations don't necessarily support every resource. The limitation you quoted is specifically about TLSRoute (SNI passthrough). BackendTLSPolicy is a different featureit allows the Gateway to terminate the client TLS session, then establish a new HTTPS/TLS connection to the backend and validate the backend certificate. So, if the add-on supports BackendTLSPolicy, it should satisfy your requirement without requiring TLSRoute. I'd recommend checking the GatewayClass capabilities or the AKS Application Routing documentation to see whether BackendTLSPolicy is currently listed as supported. If it isn't explicitly documented, I wouldn't assume it's implemented yet, even though it's part of the Gateway API specification.

Rgds,

Alex

Application routing add on Gateway API implementation Limitation Query

What that limitation means

Interpreting it for your end-to-end TLS goal

Direct answer to your question

Follow-up questions (to pinpoint the exact TLS pattern you want)

References (from provided documentation)

1 answer

Your answer