MS Entra Managed Identity in Kubernetes

Introduction

One of the most common mistakes I see teams make when running workloads on Azure Kubernetes Service (AKS) is storing credentials in Kubernetes Secrets to authenticate with Azure services — hard-coded storage account keys, client secrets for app registrations, or connection strings checked in alongside manifests. These approaches create operational pain: secrets expire, rotate, and leak through logs or container image layers.

When I migrated our multi-tenant SaaS platform from key-based auth to managed identity, the difference was immediate. No more secret rotations causing 3 AM pages. No more emergency credential revocations after repository exposure incidents. No more "which team owns that service principal?" mysteries.

Microsoft Entra Managed Identity is the right-first approach for Azure workloads. This article covers both system-assigned and user-assigned managed identities, explains the modern AKS Workload Identity federation model, and provides production-ready YAML and code examples to get you running.

Table of Contents

1. What is Managed Identity?

2. System-Assigned vs User-Assigned Managed Identity

3. AKS Workload Identity Architecture

4. Setting Up AKS Workload Identity

5. System-Assigned Managed Identity on AKS

6. User-Assigned Managed Identity on AKS

7. Application Code Integration

8. Role Assignments and RBAC

9. Multiple Identities and Multi-Tenancy

10. Security Best Practices

11. Troubleshooting

12. What I Learned

---

What is Managed Identity?

Managed Identity is an Azure feature that provides an automatically managed identity in Microsoft Entra ID for applications to use when connecting to Azure resources. The Azure platform handles credential management — you never see, store, or rotate a password or certificate.

Benefits

Feature	Key-Based Auth	Managed Identity
Credential rotation	Manual, error-prone	Automatic
Secret storage	Required	Not needed
Audit trail	Limited	Full Entra audit logs
Least privilege	Hard to enforce	Enforced via RBAC
Multi-environment	Different secrets per env	Same identity, different roles
Compliance	High overhead	Built-in

---

System-Assigned vs User-Assigned Managed Identity

Understanding the difference is critical to choosing the right pattern.

System-Assigned Managed Identity

• Lifecycle tied to the resource: Created when you enable it on a specific Azure resource (e.g., an AKS node pool), deleted when that resource is deleted.

• One-to-one mapping: One system-assigned identity per resource.

• Good for: Simple, single-service scenarios. AKS node-level operations (pulling images from ACR, writing to Azure Monitor).

User-Assigned Managed Identity

• Standalone resource: Created independently, assigned to one or many resources.

• Reusable: Share the same identity across multiple pods, node pools, or even different Azure resources.

• Lifecycle independent: Deleting an AKS cluster does not delete the managed identity.

• Good for: Application workloads, multi-pod scenarios, shared identity patterns, and disaster recovery.

When to Use Which

Scenario	Recommendation
AKS pulls images from ACR	System-assigned on node pool
App reads from Azure Blob Storage	User-assigned via Workload Identity
Multi-pod shared access	User-assigned via Workload Identity
Temporary / dev clusters	System-assigned (simpler)
Production microservices	User-assigned (portable, auditable)
Disaster recovery / cluster migration	User-assigned (survives cluster deletion)

---

AKS Workload Identity Architecture

AKS Workload Identity (the successor to AAD Pod Identity v1/v2) uses OpenID Connect (OIDC) federation — a Kubernetes-native, standards-based approach. It does NOT require a DaemonSet or a mutating webhook running in your cluster (unlike the legacy pod identity solution).

Key Components

Component	Purpose
OIDC Issuer	AKS exposes a public OIDC endpoint; Entra uses it to validate KSA tokens
Federated Identity Credential	Links a Managed Identity to a specific KSA (namespace + name)
Mutating Webhook	Injects AZURE_CLIENT_ID, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN_FILE into pods
Projected Service Account Token	Short-lived Kubernetes token used as the federated credential
DefaultAzureCredential	Azure SDK credential chain; picks up injected env vars automatically

---

Setting Up AKS Workload Identity

Prerequisites

# Install/update Azure CLI extensions
az extension add --name aks-preview --upgrade
az extension add --name account --upgrade

# Register feature flags
az feature register --namespace "Microsoft.ContainerService" \
  --name "EnableWorkloadIdentityPreview"
az provider register -n Microsoft.ContainerService

Create AKS Cluster with OIDC and Workload Identity Enabled

RESOURCE_GROUP="rg-aks-demo"
CLUSTER_NAME="aks-workload-identity-demo"
LOCATION="eastus"

# Create resource group
az group create --name $RESOURCE_GROUP --location $LOCATION

# Create AKS cluster with OIDC issuer and workload identity enabled
az aks create \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --location $LOCATION \
  --node-count 2 \
  --node-vm-size Standard_D2s_v3 \
  --enable-oidc-issuer \
  --enable-workload-identity \
  --generate-ssh-keys

# Get credentials
az aks get-credentials --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

# Export OIDC issuer URL (needed later)
export OIDC_ISSUER=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query "oidcIssuerProfile.issuerUrl" -o tsv)

echo "OIDC Issuer: $OIDC_ISSUER"

Enable Workload Identity on an Existing Cluster

az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --enable-oidc-issuer \
  --enable-workload-identity

---

System-Assigned Managed Identity on AKS

System-assigned identity on AKS is primarily used at the node pool / kubelet level — allowing nodes to pull container images from Azure Container Registry (ACR) or write logs to Azure Monitor without storing credentials.

Attach ACR to AKS Using System-Assigned Identity (Kubelet Identity)

ACR_NAME="myacrregistry"

# Create ACR
az acr create \
  --resource-group $RESOURCE_GROUP \
  --name $ACR_NAME \
  --sku Basic

# Attach ACR to AKS — grants AcrPull to the kubelet's system-assigned identity
az aks update \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --attach-acr $ACR_NAME

This command automatically assigns the AcrPull role on the ACR to the AKS kubelet's managed identity. Your pods can now pull images from ACR without imagePullSecrets:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: app
          # No imagePullSecrets needed — node kubelet identity has AcrPull
          image: myacrregistry.azurecr.io/my-app:latest
          ports:
            - containerPort: 8080

System-Assigned Identity for Node-Level Azure Operations

The system-assigned kubelet identity can also be granted access to other resources:

# Get the kubelet identity principal ID
KUBELET_IDENTITY=$(az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query "identityProfile.kubeletidentity.objectId" -o tsv)

# Grant access to a Key Vault (for node-level operations)
KEY_VAULT_ID=$(az keyvault show --name mykeyvault --query id -o tsv)

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee $KUBELET_IDENTITY \
  --scope $KEY_VAULT_ID

Important: System-assigned identity at the node level gives ALL pods on that node the same access. For application workloads requiring fine-grained per-pod permissions, always use User-Assigned Managed Identity via Workload Identity instead.

---

User-Assigned Managed Identity on AKS

This is the recommended approach for application workloads. It uses Workload Identity federation to bind a Kubernetes Service Account to an Azure Managed Identity.

Step 1: Create User-Assigned Managed Identity

IDENTITY_NAME="id-my-app"
IDENTITY_NAMESPACE="my-app"
KSA_NAME="my-app-sa"

# Create the managed identity
az identity create \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME

# Export identity values
export IDENTITY_CLIENT_ID=$(az identity show \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query "clientId" -o tsv)

export IDENTITY_PRINCIPAL_ID=$(az identity show \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query "principalId" -o tsv)

export IDENTITY_TENANT_ID=$(az account show --query tenantId -o tsv)

echo "Client ID:    $IDENTITY_CLIENT_ID"
echo "Principal ID: $IDENTITY_PRINCIPAL_ID"
echo "Tenant ID:    $IDENTITY_TENANT_ID"

Step 2: Create Kubernetes Service Account

# Create namespace
kubectl create namespace $IDENTITY_NAMESPACE

# Create annotated Service Account
kubectl apply -f - <<EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: ${KSA_NAME}
  namespace: ${IDENTITY_NAMESPACE}
  annotations:
    azure.workload.identity/client-id: "${IDENTITY_CLIENT_ID}"
  labels:
    azure.workload.identity/use: "true"
EOF

Or as a YAML file:

# service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-app-sa
  namespace: my-app
  annotations:
    # Links this KSA to the User-Assigned Managed Identity
    azure.workload.identity/client-id: "00000000-0000-0000-0000-000000000000"
  labels:
    azure.workload.identity/use: "true"

Step 3: Create Federated Identity Credential

This is the critical link — it tells Entra ID to trust tokens issued by this AKS cluster's OIDC endpoint for this specific service account.

az identity federated-credential create \
  --name "fedcred-${KSA_NAME}" \
  --identity-name $IDENTITY_NAME \
  --resource-group $RESOURCE_GROUP \
  --issuer "${OIDC_ISSUER}" \
  --subject "system:serviceaccount:${IDENTITY_NAMESPACE}:${KSA_NAME}" \
  --audience "api://AzureADTokenExchange"

Step 4: Grant Azure RBAC to the Managed Identity

# Example: Grant access to a specific Key Vault
KEY_VAULT_ID=$(az keyvault show \
  --name "my-keyvault" \
  --resource-group $RESOURCE_GROUP \
  --query id -o tsv)

az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope $KEY_VAULT_ID

# Example: Grant access to a specific Storage Account container
STORAGE_ID=$(az storage account show \
  --name "mystorageaccount" \
  --resource-group $RESOURCE_GROUP \
  --query id -o tsv)

az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "${STORAGE_ID}/blobServices/default/containers/my-container"

Step 5: Deploy Your Pod with Workload Identity

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
        # This label triggers the Workload Identity webhook
        azure.workload.identity/use: "true"
    spec:
      # Reference the annotated Service Account
      serviceAccountName: my-app-sa
      containers:
        - name: app
          image: myacrregistry.azurecr.io/my-app:latest
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 512Mi
          # The webhook injects these automatically — shown for clarity:
          # env:
          #   - name: AZURE_CLIENT_ID
          #     value: "<client-id>"
          #   - name: AZURE_TENANT_ID
          #     value: "<tenant-id>"
          #   - name: AZURE_FEDERATED_TOKEN_FILE
          #     value: /var/run/secrets/azure/tokens/azure-identity-token
          #   - name: AZURE_AUTHORITY_HOST
          #     value: https://login.microsoftonline.com/

After the webhook mutates the pod, you can verify the injected environment:

kubectl exec -n my-app deployment/my-app -- env | grep AZURE
# AZURE_CLIENT_ID=00000000-0000-0000-0000-000000000000
# AZURE_TENANT_ID=00000000-0000-0000-0000-000000000000
# AZURE_FEDERATED_TOKEN_FILE=/var/run/secrets/azure/tokens/azure-identity-token
# AZURE_AUTHORITY_HOST=https://login.microsoftonline.com/

---

Application Code Integration

The beauty of managed identity is that your application code uses DefaultAzureCredential — the same code works locally (via az login) and in AKS (via Workload Identity) without any changes.

Go

package main

import (
    "context"
    "fmt"
    "log"

    "github.com/Azure/azure-sdk-for-go/sdk/azidentity"
    "github.com/Azure/azure-sdk-for-go/sdk/keyvault/azsecrets"
)

func main() {
    // DefaultAzureCredential picks up AZURE_CLIENT_ID, AZURE_TENANT_ID,
    // AZURE_FEDERATED_TOKEN_FILE automatically when running in AKS with
    // Workload Identity — no code changes needed between local and prod.
    cred, err := azidentity.NewDefaultAzureCredential(nil)
    if err != nil {
        log.Fatalf("failed to obtain credential: %v", err)
    }

    vaultURL := "https://my-keyvault.vault.azure.net/"
    client, err := azsecrets.NewClient(vaultURL, cred, nil)
    if err != nil {
        log.Fatalf("failed to create secrets client: %v", err)
    }

    ctx := context.Background()
    secretName := "database-password"

    resp, err := client.GetSecret(ctx, secretName, "", nil)
    if err != nil {
        log.Fatalf("failed to get secret: %v", err)
    }

    fmt.Printf("Secret value: %s\n", *resp.Value)
}

Python

from azure.identity import DefaultAzureCredential
from azure.keyvault.secrets import SecretClient
from azure.storage.blob import BlobServiceClient

# Works locally (az login) and in AKS (Workload Identity) — no code changes
credential = DefaultAzureCredential()

# Key Vault
vault_url = "https://my-keyvault.vault.azure.net/"
secret_client = SecretClient(vault_url=vault_url, credential=credential)
secret = secret_client.get_secret("database-password")
print(f"Secret: {secret.value}")

# Storage
storage_client = BlobServiceClient(
    account_url="https://mystorageaccount.blob.core.windows.net",
    credential=credential
)
container_client = storage_client.get_container_client("my-container")

Node.js / TypeScript

import { DefaultAzureCredential } from "@azure/identity";
import { SecretClient } from "@azure/keyvault-secrets";

async function main() {
  // No configuration needed — reads AZURE_* env vars injected by webhook
  const credential = new DefaultAzureCredential();

  const vaultUrl = "https://my-keyvault.vault.azure.net/";
  const client = new SecretClient(vaultUrl, credential);

  const secret = await client.getSecret("database-password");
  console.log(`Secret value: ${secret.value}`);
}

main().catch(console.error);

---

Role Assignments and RBAC

Least-privilege role assignments are central to managed identity security. Always scope to the minimum necessary resource.

Common Role Assignments

# Key Vault: Read secrets only
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault>"

# Key Vault: Read, set, delete secrets (for secret rotation jobs)
az role assignment create \
  --role "Key Vault Secrets Officer" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault>"

# Storage Blob: Read only
az role assignment create \
  --role "Storage Blob Data Reader" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"

# Storage Blob: Read and write
az role assignment create \
  --role "Storage Blob Data Contributor" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>"

# Service Bus: Send messages
az role assignment create \
  --role "Azure Service Bus Data Sender" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.ServiceBus/namespaces/<namespace>"

# Cosmos DB: Read data
az role assignment create \
  --role "Cosmos DB Account Reader Role" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.DocumentDB/databaseAccounts/<account>"

Scope Examples

# Subscription-level (too broad for most cases)
--scope "/subscriptions/<subscription-id>"

# Resource group level
--scope "/subscriptions/<sub>/resourceGroups/<rg>"

# Specific resource (recommended)
--scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/<provider>/<resource>"

# Specific container within storage account (most restrictive)
--scope "/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>/blobServices/default/containers/<container>"

---

Multiple Identities and Multi-Tenancy

In a multi-team cluster, different services should have different managed identities.

Pattern: One Identity Per Workload

# Team A: payment-service
az identity create --name "id-payment-service" --resource-group $RESOURCE_GROUP
az identity federated-credential create \
  --name "fedcred-payment-service" \
  --identity-name "id-payment-service" \
  --resource-group $RESOURCE_GROUP \
  --issuer $OIDC_ISSUER \
  --subject "system:serviceaccount:payments:payment-service-sa" \
  --audience "api://AzureADTokenExchange"

# Team B: inventory-service
az identity create --name "id-inventory-service" --resource-group $RESOURCE_GROUP
az identity federated-credential create \
  --name "fedcred-inventory-service" \
  --identity-name "id-inventory-service" \
  --resource-group $RESOURCE_GROUP \
  --issuer $OIDC_ISSUER \
  --subject "system:serviceaccount:inventory:inventory-service-sa" \
  --audience "api://AzureADTokenExchange"

Each service account in its own namespace maps to its own managed identity with its own scoped role assignments.

Managing With Terraform

# managed_identity.tf
resource "azurerm_user_assigned_identity" "payment_service" {
  name                = "id-payment-service"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
}

resource "azurerm_federated_identity_credential" "payment_service" {
  name                = "fedcred-payment-service"
  resource_group_name = azurerm_resource_group.main.name
  parent_id           = azurerm_user_assigned_identity.payment_service.id

  audience = ["api://AzureADTokenExchange"]
  issuer   = azurerm_kubernetes_cluster.main.oidc_issuer_url
  subject  = "system:serviceaccount:payments:payment-service-sa"
}

resource "azurerm_role_assignment" "payment_kv" {
  scope                = azurerm_key_vault.main.id
  role_definition_name = "Key Vault Secrets User"
  principal_id         = azurerm_user_assigned_identity.payment_service.principal_id
}

---

Security Best Practices

1. Avoid Node-Level Identity for Application Access

# BAD: Grant Key Vault access to the node kubelet identity
# This means ALL pods on every node can access Key Vault
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee $KUBELET_IDENTITY \
  --scope $KEY_VAULT_ID

# GOOD: Use Workload Identity — scoped to a specific KSA
az role assignment create \
  --role "Key Vault Secrets User" \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --scope $KEY_VAULT_ID

2. Always Scope Roles to Specific Resources

Never assign roles at the subscription level for application workloads.

3. Restrict Federated Credential Subject Precisely

The subject in a federated credential must be system:serviceaccount:<namespace>:<name>. Wildcards are not supported; this is intentional security enforcement.

4. Separate Identities Per Environment

# dev environment
az identity create --name "id-payment-service-dev" --resource-group "rg-dev"

# prod environment
az identity create --name "id-payment-service-prod" --resource-group "rg-prod"

5. Use Azure Policy to Prevent Credential Leakage

{
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.ContainerService/managedClusters"
        },
        {
          "field": "Microsoft.ContainerService/managedClusters/oidcIssuerProfile.enabled",
          "notEquals": true
        }
      ]
    },
    "then": {
      "effect": "Deny"
    }
  }
}

6. Monitor Identity Usage

# Check role assignments for a managed identity
az role assignment list --assignee $IDENTITY_PRINCIPAL_ID --all -o table

# Review federated credentials
az identity federated-credential list \
  --identity-name $IDENTITY_NAME \
  --resource-group $RESOURCE_GROUP \
  -o table

---

Troubleshooting

Webhook Not Injecting Environment Variables

# Verify workload identity is enabled on the cluster
az aks show \
  --resource-group $RESOURCE_GROUP \
  --name $CLUSTER_NAME \
  --query "securityProfile.workloadIdentity"

# Verify the webhook pods are running
kubectl get pods -n kube-system | grep workload-identity

# Verify pod has the label
kubectl get pod <pod-name> -n <namespace> -o yaml | grep "azure.workload.identity/use"

AADSTS70021: No Matching Federated Identity Record Found

This means the federated credential subject doesn't match the pod's actual service account.

# Check what subject the token is being presented with
kubectl exec -n <namespace> <pod-name> -- cat $AZURE_FEDERATED_TOKEN_FILE | \
  cut -d. -f2 | base64 -d 2>/dev/null | python3 -m json.tool | grep sub

# The output should match your federated credential subject exactly:
# "sub": "system:serviceaccount:<namespace>:<serviceaccount-name>"

AADSTS50034: User Account Does Not Exist

The managed identity's principal ID was not found in the tenant — usually means the role assignment used the wrong assignee or the identity is in a different subscription.

# Verify the identity exists and is in the right tenant
az identity show \
  --resource-group $RESOURCE_GROUP \
  --name $IDENTITY_NAME \
  --query "{clientId:clientId, principalId:principalId, tenantId:tenantId}"

Pod Can't Access Azure Resource (403 Forbidden)

# Check role assignments
az role assignment list \
  --assignee $IDENTITY_PRINCIPAL_ID \
  --all \
  --query "[].{Role:roleDefinitionName, Scope:scope}" \
  -o table

# Check if role assignment propagation has completed (can take ~1-2 minutes)
# Try re-running the request after a short wait

Check Token Exchange is Working

# Get the federated token from inside the pod
kubectl exec -n <namespace> <pod-name> -- \
  cat /var/run/secrets/azure/tokens/azure-identity-token

# Manually exchange the token (for debugging)
kubectl exec -n <namespace> <pod-name> -- \
  curl -s -X POST \
    "https://login.microsoftonline.com/${AZURE_TENANT_ID}/oauth2/v2.0/token" \
    -d "grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer" \
    -d "client_id=${AZURE_CLIENT_ID}" \
    -d "client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer" \
    -d "client_assertion=$(cat /var/run/secrets/azure/tokens/azure-identity-token)" \
    -d "scope=https://vault.azure.net/.default" \
    -d "requested_token_use=on_behalf_of"

---

What I Learned

After migrating dozens of services from key-based authentication to managed identity, here are the lessons that saved me the most time:

1. User-assigned is almost always the right choice for applications. System-assigned makes sense only for node-level operations like ACR pulling. For everything else, user-assigned gives you portability, reuse, and survivability across cluster recreations.

2. The federated credential subject must be exact. The format is system:serviceaccount:<namespace>:<name> — no wildcards. Get this wrong and you'll waste hours on confusing AADSTS errors.

3. Role assignment propagation takes time. Azure RBAC changes can take 1–2 minutes to propagate. In CI/CD pipelines, add a sleep 60 or retry loop after granting permissions.

4. DefaultAzureCredential is the right primitive. Don't use WorkloadIdentityCredential directly unless you have a specific reason. DefaultAzureCredential works locally with az login, in AKS with Workload Identity, and in any other Azure compute — same code everywhere.

5. Always scope to the minimum resource, not the resource group. Key Vault at vault scope, Storage at container scope. It's more verbose in Terraform/CLI but dramatically reduces blast radius.

6. Label the pod, not just the service account. Both the Service Account annotation (azure.workload.identity/client-id) AND the pod label (azure.workload.identity/use: "true") are required. Missing either one means the webhook won't inject credentials.

7. Separate identities per environment, per service. A single shared managed identity across dev/prod is a compliance and blast radius problem waiting to happen.

---

Summary

Next steps:

• Kubernetes 101: AWS IAM in Kubernetes (EKS)

• Kubernetes 101: Configuration and Secrets

• Kubernetes 101: Namespaces and RBAC