TechOps Examples

Hey — It's Govardhana MK 👋

Welcome to another technical edition.

Every Tuesday – You’ll receive a free edition with a byte-size use case, remote job opportunities, top news, tools, and articles.

Every Thursday and Saturday – You’ll receive a special edition with a deep dive use case, remote job opportunities, and articles.

👋 Before we begin... a big thank you to today's sponsor AI REPORT

90% of AI content is noise. The AI Report is the 10%.

We cover real enterprise deployments, actual business outcomes, and the AI strategies leaders are betting on right now — not lab experiments, not demos, not speculation.

400,000+ executives, operators, and founders read us every weekday to cut through the clutter and make faster, smarter decisions about AI before their competitors do.

No hype. No fluff. Just the signal.

See what's actually working in AI across every industry right now — free, in 5 minutes a day.

Cut through the noise

Powered by: Jobsurface.com

Browse 855 Worldwide Jobs Here →

Looking to promote your company, product, service, or event to 55,000+ Cloud Native Professionals? Let's work together. Advertise With Us

The moment your Kubernetes workload handles real user traffic, stores sensitive data, or runs inside a regulated industry, every networking decision becomes a security decision. Who can reach the cluster? How do TLS certificates get provisioned and rotated? Where do secrets live? How does outbound traffic leave the cluster without exposing your private network?

Azure Kubernetes Service removes the operational burden of managing the Kubernetes control plane. But the responsibility for securing the workload, the network boundary, the certificate chain, and the secrets lifecycle sits entirely with the platform engineer. AKS gives you the primitives. The architecture is yours to design.

We walk through a production grade AKS reference architecture that solves all of these problems together, starting with how a request enters the system and ending with how the cluster reaches the internet on its own terms.

The below image shows the numbered sequence of how a real HTTPS request travels from a client application to a pod running inside AKS. Following this path in order is the fastest way to understand why each component exists.

Step 1: DNS resolution. The client application makes a DNS query for store.test.com. Azure DNS zone resolves this hostname and returns the anycast IP address of Azure Front Door. This is the only public facing entry point in the entire architecture. Nothing else has a public IP that accepts inbound traffic.

Step 2: HTTPS termination at Azure Front Door. The client connects over HTTPS to Azure Front Door. Front Door is a global load balancer and CDN with a built-in Web Application Firewall policy. TLS is terminated here using a digital certificate with CN=store.test.com stored in Azure Key Vault. The certificate was provisioned by an administrator or platform engineer at deployment time (step 1 on the deployment time path) and is retrieved by Front Door at runtime (step 4 on the runtime path). This means your application team never manually handles private keys. The certificate lifecycle is managed through Key Vault, and Front Door fetches it automatically.

Step 3: Private endpoint traversal. After TLS termination, Front Door forwards traffic through a private endpoint into the virtual network. This private endpoint has no public IP. It is a private network interface sitting inside the VNet with a private IP address. Traffic from the public internet to your AKS workload never traverses the public internet after leaving Front Door. The connection from Front Door's global network into your VNet is entirely private.

Step 4: Private Link service. The private endpoint connects to a Private Link service sitting in the VmSubnet at 10.243.1.0/24. The Private Link service has a private IP address of 10.243.1.9. It acts as the bridge between the Front Door private endpoint and the internal load balancer inside the AKS cluster network.

Step 5: AKS internal load balancer. The traffic reaches the SystemSubnet at 10.240.0.0/16, where the AKS cluster's internal standard load balancer sits. This load balancer fronts the NGINX ingress controller service, which has been assigned the private IP 10.240.0.7. This is a Kubernetes Service of type LoadBalancer that Azure has provisioned as an internal load balancer, meaning it has no public IP and is only reachable from within the VNet.

Step 6: AKS agent nodes. The load balancer distributes traffic to the AKS agent nodes sitting in the UserSubnet at 10.241.0.0/16. These nodes have private IPs in the 10.241.0.4 to 10.241.0.6 range.

Step 7: TLS secret injection via Secrets Store CSI Driver. Inside the cluster, the NGINX ingress controller pod needs the TLS certificate to terminate HTTPS connections for the store.test.com hostname. The Secrets Store CSI Driver with a SecretProviderClass resource mounts the certificate from Azure Key Vault directly into the pod as a Kubernetes Secret at deployment time. This is the path from Key Vault into the cluster: not a manual kubectl create secret command, not a hardcoded value in a YAML file, but a managed sync from Key Vault that respects rotation and access policies.

Step 8: Ingress routing. The NGINX ingress pod, now holding the TLS secret, terminates the HTTPS connection and routes the decrypted request based on the hostname store.test.com to the appropriate backend Service and Deployment in the httpbin-tls namespace.

The result is an end-to-end request path where TLS is enforced at the edge, traffic is private from Front Door inward, certificate management is automated through Key Vault, and no pod directly handles secret provisioning logic.

🔴 Get my DevOps & Kubernetes ebooks! (free for Premium Club and Personal Tier newsletter subscribers)