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

Yang, Bin Bin 20 Reputation points
2026-07-15T06:39:29.6133333+00:00

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

Azure Kubernetes Service
Azure Kubernetes Service

An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance.

0 comments
Answer accepted by question author
Christos Panagiotidis 3,551 Reputation points
2026-07-15T07:28:50.49+00:00

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.

Was this answer helpful?

2 people found this answer helpful.

0 additional answers

Sort by: Most helpful
Most helpful Newest Oldest

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.