Secrets Management in AKS with Azure Workload Identity

aks secrets store csi driver

Managing secrets across dozens of websites and APIs in Azure Kubernetes Service (AKS) can be a nightmare if you’re still using static credentials. Hardcoded secrets, long-lived keys, and manual rotations increase the risk of exposure and slow down deployments. On Azure Kubernetes Service (AKS), we’ve evolved with the Secrets Store CSI Driver, Azure Key Vault, and Workload Identity Federation.

This setup enables every pod – across all your websites – to mount secrets directly from Key Vault as ephemeral volumes, authenticated via OpenID Connect (OIDC) tokens. No secrets in code, no keys to manage – just dynamic, federated identities.

In this guide, we’ll build a zero-trust, fully automated secret management system using:

Terraform for dynamic provisioning
Azure Workload Identity Federation for secure, token-based authentication
Secrets Store CSI Driver + Azure Key Vault Provider for ephemeral secret access

Perfect for multi-tenant platforms like Coderise, where each website needs isolated, dynamic access to its secrets – without managing credentials manually.

Why Federated Workload Identity?

Traditional Kubernetes secrets are stored in etcd and base64 encoded – not ideal for production security. Workload Identity Federation replaces credentials with OIDC-issued tokens that Azure trusts, meaning no keys, no rotations, no leaks.

How it works:

AKS issues an OIDC token for a pod’s service account.
Azure trusts that token through a federated credential tied to a User-Assigned Managed Identity (UAMI).
The pod authenticates to Azure Key Vault using that token – no secret stored in the cluster.

Architecture Overview

Each website (namespace) gets its own Kubernetes service account dynamically federated to Azure via Terraform.

Step 1: AKS Setup with Workload Identity

Enable OIDC and Workload Identity when creating your AKS cluster:



resource "azurerm_kubernetes_cluster" "aks" {

name                = "coderise-aks"

location            = azurerm_resource_group.rg.location

resource_group_name = azurerm_resource_group.rg.name

dns_prefix          = "coderise"

oidc_issuer_enabled = true
workload_identity_enabled = trueidentity {
type = “UserAssigned”
identity_ids = [azurerm_user_assigned_identity.cluster.id]
}default_node_pool {
name = “system”
node_count = 2
vm_size = “Standard_DS2_v2”
}role_based_access_control_enabled = true
}

Step 2: Key Vault & Identity Configuration

Create your Key Vault and grant your kv_identity read access to secrets.



# User-Assigned Managed Identity used to access Key Vault

resource "azurerm_user_assigned_identity" "kv_identity" {

name                = "define-name-of-identity"

location            = azurerm_resource_group.rg.location

resource_group_name = azurerm_resource_group.rg.name

}

# Key Vault with safe defaultsresource “azurerm_key_vault” “main” {
name = “coderise-kv”
location = azurerm_resource_group.rg.location
resource_group_name = azurerm_resource_group.rg.name
sku_name = “standard”
soft_delete_retention_days = 7
purge_protection_enabled = true
}# Grant the UAMI permission to GET & LIST secretsresource “azurerm_key_vault_access_policy” “kv_policy” {
key_vault_id = azurerm_key_vault.main.id
tenant_id = data.azurerm_client_config.current.tenant_id
object_id = azurerm_user_assigned_identity.kv_identity.principal_idsecret_permissions = [“Get”, “List”]
}

Step 3: Dynamic Federated Identity Loop in Terraform

Here’s where the automation magic happens. For each website’s service account, Terraform creates a federated credential linking AKS → Azure.



variable "website_service_accounts" {

type    = list(string)

default = ["site-a", "site-b", "site-c"]

}

# Create a federated credential for each website’s service account

resource “azurerm_federated_identity_credential” “website_federations” {
for_each = toset(var.website_service_accounts)name = “${each.key}-federation”
resource_group_name = azurerm_resource_group.rg.name
parent_id = azurerm_user_assigned_identity.kv_identity.id
issuer = azurerm_kubernetes_cluster.aks.oidc_issuer_url# IMPORTANT: subject must match the Kubernetes ServiceAccount exactly:# “system:serviceaccount::”subject = “system:serviceaccount:${each.key}:${each.key}-sa”
audience = [“api://AzureADTokenExchange”]
}Result: One terraform apply dynamically federates every website’s service account.Step 4: Install CSI Driver and Azure Provider

After connecting to your AKS cluster, install the CSI driver and Azure provider via Helm:



# Get credentials for kubectl

az aks get-credentials -g coderise-rg -n coderise-aks

# Install Secrets Store CSI Driver and Azure providerhelm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts

helm upgrade -i csi secrets-store-csi-driver/secrets-store-csi-driver
–namespace kube-system
–set syncSecret.enabled=true
–set enableSecretRotation=true
–set rotationPollInterval=1m

helm upgrade -i azure-provider secrets-store-csi-driver/provider-azure
–namespace kube-system

This installs the CSI driver with secret rotation enabled and optional Kubernetes secret syncing.

Step 5: Kubernetes Setup per Website

Each website gets its own namespace, service account, and SecretProviderClass. Keep things isolated.

ServiceAccount

SecretProviderClass

Pod Mount Example

Lessons Learned

Namespace Mismatch = Token Denial: Always match your Terraform subject with the Kubernetes ServiceAccount namespace. E.g. system:serviceaccount:site-a:site-a-sa.
Secret Rotation Lag: First mounts may delay a bit; set rotationPollInterval=1m for production.
Scale-Friendly: Terraform loops easily handle 50+ websites; modularize to keep plans fast.

Troubleshooting Quick Wins

Check CSI logs: kubectl logs -n kube-system -l app=csi-secrets-store-provider-azure
Validate federated credentials: az identity federated-credential list --id <uami-id>
Verify subject formatting: Mistyped namespaces or service account names are the most common cause of denials.

Best Practices

Automation: Source the website service account list from CI/CD variables or a config repo to avoid manual edits.
Network Security: Use Key Vault private endpoints and VNet ACLs to limit access.
Monitoring: Enable Azure Monitor and diagnostic logs for Key Vault and AKS; alert on access anomalies.
Template Deployments: Use Helm or Kustomize to standardize per-site ServiceAccount, SecretProviderClass, and deployment manifests.

Resources & Further Reading

Azure Workload Identity Federation – Microsoft Docs
Secrets Store CSI Driver for Azure Key Vault – Microsoft Docs
Terraform azurerm_federated_identity_credential – Terraform Registry

Secure Secrets Management in AKS architecture diagram

Secure Secrets Management in AKS - Terraform and CSI workflow

November 4, 20253 Free and Simple Cloudflare Rules to Protect WordPress

October 22, 2025Secrets Management in AKS with Azure Workload Identity

September 10, 2024Get kubernetes logs easily using kubectl

September 2, 2024Delete multiple jobs in Kubernetes

July 25, 2024Create User in InfluxDB without Operator Token