How to configure my AKS network setup in a enterprise zero trust private environment

Question

How to configure my AKS network setup in a enterprise zero trust private environment

Yang, Bin Bin 20

Good day,

For my enterprise company I am creating a design for a to be developed AKS platform setup. I'm having trouble to figure out what the best practices from Microsoft are for my setup. The context is as follows:

Enterprise setup, more than 100+ workloads will eventually run on AKS
Zero trust security strategy
AKS workloads will connect to on-premise network and to public internet
All communication, ingress and egress, from AKS will go through a central connectivity hub
Company does not want a fully managed AKS with all managed services from Azure, as stakeholders require a valid exit strategy, so where available platform should choose Cloudnative solutions

Based on the best practices I could find within Azure and the Kubernetes community, I see my setup as follows:

Ingress traffic goes from:
On-premise/Public internet -> Connectivity Hub managed by Central Cloud team -> Application Gateway + Web Application Firewall of an AKS cluster -> Kubernetes Gateway API provider (will be Istio for us) ->AKS Cluster

Egress traffic goes from:
AKS Cluster -> UDR -> Connectivity Hub -> On-premise/Public internet.

The most complex thing in this setup seems to be TLS termination and Certificate management as traffic has to go through the Application Gateway + WAF and then to my Gateway API.

I'm basing my setup on
https://learn.microsoft.com/en-us/azure/aks/operator-best-practices-network
https://learn.microsoft.com/en-us/azure/aks/app-routing-gateway-api-tls

https://learn.microsoft.com/en-us/azure/aks/intro-aks-automatic#aks-automatic-and-standard-feature-comparison

https://learn.microsoft.com/en-us/azure/architecture/reference-architectures/containers/aks/baseline-aks

Could you support me and guide me in the right direction?

Kinds regards,

Bin Bin Yang

0 comments

Answer accepted by question author

0 additional answers

Your answer

Answer 1

Christos Panagiotidis 3,551

Your pattern is sound, but make Application Gateway WAF the only internet-facing L7 edge and keep Istio as the in-cluster gateway and service-mesh boundary. Do not expose a second public load balancer.

Use a private AKS cluster in a spoke. Keep the API server private and make its private DNS zone resolvable from the hub and on-premises DNS.
Use Azure CNI. Choose Overlay when no external system needs to reach pod IPs directly; choose CNI Pod Subnet when routable pod IPs are required. Reserve non-overlapping ranges and upgrade headroom.
Set AKS outbound type to userDefinedRouting and route the relevant AKS subnets' default route to the hub firewall. Explicitly allow the AKS-required outbound endpoints before enforcing the route.
Terminate client TLS at Application Gateway so WAF can inspect it, then re-encrypt to the Istio gateway/internal load balancer. Use Key Vault for the listener certificate, a separate trusted backend certificate, and the correct backend hostname/SNI. Use Istio mTLS for service-to-service traffic.

For 100+ workloads, split clusters by environment, region, compliance boundary, or blast radius—not simply by application count—and enforce namespace isolation and default-deny network policies within each cluster.

Yang, Bin Bin 20 Reputation points

2026-07-23T07:43:14.82+00:00

Thank you Christos for your feedback. I really appreciate it
binbin yang 0 Reputation points

2026-07-27T09:59:05.7+00:00

Hey Christos, thank you very much for your feedback. It helped me a lot. I have a follow up question regarding the Application Gateway. Would you deploy this in a seperate Vnet Spoke or deploy it in the same Vnet Spoke as the AKS cluster. Also would you opt for a central Application Gateway wich can be shared between DTAP K8s clusters, or would you choose for a dedicated Application Gateway per cluster.