Azure AKS Enterprise Platform
AKS with Workload Identity, Key Vault and Azure DevOps
Basis: Reference architecture. Draws on Azure skills listed on the CV (AKS, Azure DevOps, Key Vault, Entra ID); not presented as a production deployment. Never applied against a real Azure subscription.
Overview
A reference AKS platform: hub-and-spoke networking, private AKS, Azure Container Registry, Key Vault through the CSI driver with Microsoft Entra Workload ID, and Azure DevOps pipelines.
Problem
Teams moving to AKS often start with a public cluster, admin credentials in pipelines and secrets in Kubernetes objects.
Solution
Private AKS in a spoke VNet, egress through a hub firewall, workload identity federation for pods and pipelines, and Key Vault as the only secret store.
Architecture
Hub VNet
Azure Firewall
egress control
Bastion
Spoke VNet
AKS (private)
system + user pools
Private endpoints
ACR, Key Vault
Platform services
ACR
Key Vault
CSI driver
Log Analytics
Delivery
Azure DevOps
workload identity federation
Technology stack
- AKS
- Azure Container Registry
- Azure DevOps
- Azure Key Vault
- Entra Workload ID
- Azure Monitor
- Log Analytics
- Azure Firewall
- Terraform
- Helm
Implementation
- Six Terraform modules: hub (VNet, Azure Firewall, Bastion), spoke (peered VNet with forced tunneling through the firewall), aks (private cluster), platform (ACR + Key Vault + Log Analytics), plus separate workload-identity and pipeline-identity modules so onboarding a new pod or pipeline never touches the cluster's own state.
- Azure RBAC for Kubernetes authorization tied to Entra groups, with local (username/password, client-cert) Kubernetes accounts disabled entirely.
- Azure Policy add-on enforcing baseline pod security, plus system/user/spot node pools spread across availability zones.
- A Key Vault CSI driver demo chart showing a SecretProviderClass authenticated via Entra Workload ID — no pod identity add-on, no client secret.
Security
- Local accounts disabled on AKS — Azure RBAC with Entra groups is the only path to cluster access.
- No client secrets anywhere: both pod identity (Workload Identity federated credentials) and the Azure DevOps pipeline identity (federated credential trusting Azure DevOps's OIDC issuer, scoped to AcrPush only) use federated credentials, never a stored secret.
- Private endpoints for ACR and Key Vault, both with public network access disabled.
Reliability
- Availability zones for all node pools.
- Separate system (critical-addons-only) and user/spot node pools, so a workload crash can't starve cluster system components.
Cost
- Azure Firewall is a significant fixed cost; share one hub across spokes rather than one firewall per environment.
- Spot node pools for interruptible workloads cut compute cost where a pod can tolerate eviction.
Results
No quantified results are published for this project. Figures from client work are confidential, and this portfolio only shows numbers that can be verified or reproduced.
Code & documentation
Lessons learned
- Private clusters need a plan for how CI reaches the API server before you create them — Bastion plus a private DevOps agent, decided up front, not retrofitted.
- Project-level or cluster-level authoritative settings belong in exactly one module; granting cross-module role assignments from a shared root avoids a dependency cycle between modules that each need the other's output.