Skip to content

Azure AKS Enterprise Platform

AKS with Workload Identity, Key Vault and Azure DevOps

Reference architectureImplemented & validated locally

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

  1. Hub VNet

    • Azure Firewall

      egress control

    • Bastion

  2. Spoke VNet

    • AKS (private)

      system + user pools

    • Private endpoints

      ACR, Key Vault

  3. Platform services

    • ACR

    • Key Vault

      CSI driver

    • Log Analytics

  4. Delivery

    • Azure DevOps

      workload identity federation

Hub-and-spoke: egress is centralized in the hub.

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.