Security on AKS: Azure AD, RBAC, and Key Vault

Why this matters

You already know Kubernetes-native RBAC (Role/RoleBinding) from the local Kubernetes track, and Kubernetes Secret objects. On a real cloud cluster with real people and real credentials, two gaps show up: first, you want cluster access tied to actual Azure user identities (not shared kubeconfig files), and second, Kubernetes Secret objects are only base64-encoded, not encrypted-at-rest-by-default-with-strong-guarantees, and don't rotate — a real secrets story means pulling from Azure Key Vault instead. This module covers both.

Concepts

Kubernetes RBAC vs. Azure AD-integrated Kubernetes RBAC. Plain Kubernetes RBAC (what you used locally) authorizes based on identities the API server is told about — often static service account tokens or client certs, with no central directory. Azure AD-integrated RBAC lets you bind Kubernetes Role/ClusterRole objects to real Azure AD users/groups, so cluster access follows your organization's actual identity system: someone leaving the team loses cluster access when their Azure AD account is disabled, without you touching kubeconfigs. AKS also offers Azure RBAC for Kubernetes Authorization, which goes a step further and lets you manage Kubernetes permissions as Azure role assignments (az role assignment create) instead of RoleBinding YAML at all — useful when you want one consistent permissions model across Azure and Kubernetes.

Managed identities, recap and extension. You met the cluster's managed identity in module 03 (for ACR pulls). Individual workloads can also get their own scoped identity via workload identity (Azure AD Workload Identity federation), letting a specific Pod authenticate to Azure services (like Key Vault) as itself, rather than the whole cluster sharing one broad identity.

Azure Key Vault + the Secrets Store CSI Driver. Instead of kubectl create secret storing values inside the cluster's etcd, the Azure Key Vault Provider for Secrets Store CSI Driver mounts secrets from Key Vault into a Pod as files (and can optionally sync them into a regular Kubernetes Secret too), at pod-start time. The secret's source of truth stays in Key Vault — with its own access policies, rotation, and audit log — rather than being duplicated and frozen inside the cluster.

What AKS manages vs. what you own: Azure AD-integration and workload identity federation plumbing is managed by Azure once enabled; you still own which users/groups get which Role/ClusterRole bindings (or Azure role assignments), what secrets live in Key Vault and their access policies, and — critically — you still need to design least-privilege roles yourself. None of this is automatic just because it's "AKS."

Command reference

Hands-on exercises

1. Enable Azure AD integration on your cluster. Run az aks update --resource-group rg-aks-learn --name aks-learn --enable-aad. This takes a few minutes. Verify: az aks show --resource-group rg-aks-learn --name aks-learn --query aadProfile shows a populated AAD profile.

2. Re-fetch credentials and observe the login change. Run az aks get-credentials --resource-group rg-aks-learn --name aks-learn --overwrite-existing, then run any kubectl command, e.g. kubectl get nodes. Verify: you get prompted to authenticate interactively via a device-code/browser flow (through kubelogin) the first time — this is Azure AD auth replacing the old static credential.

3. Create (or identify) an Azure AD group for a role, and bind it. If you have access to create one, create an Azure AD security group for "aks-viewers" (via portal or az ad group create if available to your account); otherwise use your own user's object ID for this exercise (az ad signed-in-user show --query id -o tsv). Write a ClusterRoleBinding whose subjects references that Azure AD group/user object ID with kind: Group or kind: User, bound to the built-in view ClusterRole. Apply it and verify with kubectl auth can-i list pods --as=<object-id> (or test directly by authenticating as that identity) that read access works but write access doesn't (kubectl auth can-i delete pods --as=<object-id> should say no).

4. Create a Key Vault and a secret. Run az keyvault create --resource-group rg-aks-learn --name kv-aks-learn --location eastus (name must be globally unique), then az keyvault secret set --vault-name kv-aks-learn --name db-password --value "s3cr3t-value". Verify: az keyvault secret show --vault-name kv-aks-learn --name db-password --query value -o tsv returns the value.

5. Enable the Key Vault CSI driver add-on. Run az aks enable-addons --resource-group rg-aks-learn --name aks-learn --addons azure-keyvault-secrets-provider. Verify: kubectl get pods -n kube-system -l app=secrets-store-csi-driver shows driver pods running, and az aks show --resource-group rg-aks-learn --name aks-learn --query addonProfiles.azureKeyvaultSecretsProvider.enabled returns true.

6. Grant the add-on's identity access to your vault. Find the identity's object/client ID from az aks show --resource-group rg-aks-learn --name aks-learn --query addonProfiles.azureKeyvaultSecretsProvider.identity, then run az keyvault set-policy --name kv-aks-learn --object-id <identity-object-id> --secret-permissions get. Verify the policy exists: az keyvault show --name kv-aks-learn --query properties.accessPolicies.

7. Mount the secret into a Pod. Write a SecretProviderClass referencing kv-aks-learn and the db-password secret, and a Pod spec mounting it via the CSI volume. Apply both, then verify: kubectl exec <pod-name> -- cat /mnt/secrets-store/db-password prints the value — pulled live from Key Vault, not stored as a Kubernetes Secret you created by hand.

8. Diagnose and fix: access denied pulling the secret. Deliberately remove the access policy (az keyvault delete-policy --name kv-aks-learn --object-id <identity-object-id>), delete and recreate the Pod, and verify it fails to start (check kubectl describe pod for a mount/CSI error mentioning access denied/Forbidden). Fix it by re-running the az keyvault set-policy command from exercise 6, recreate the pod, and confirm the mount succeeds again.

9. Clean up. Delete the test Pod/SecretProviderClass/RoleBinding: kubectl delete pod <name>, kubectl delete secretproviderclass <name>, kubectl delete clusterrolebinding <name>. Key Vault has a low ongoing cost per vault/operation, but delete it if you don't need it beyond this module: az keyvault delete --name kv-aks-learn --resource-group rg-aks-learn (note Key Vault has soft-delete by default — also consider az keyvault purge --name kv-aks-learn if you want it fully gone and your subscription permits purging, otherwise it lingers in a recoverable-but-still-billed-lightly state for a retention period). Disable the CSI driver add-on if unused going forward: az aks disable-addons --resource-group rg-aks-learn --name aks-learn --addons azure-keyvault-secrets-provider.

Independent challenge

No commands given here — figure it out yourself using what you know from this module and earlier ones.

Task: Get a real secret into a running Pod without ever creating a Kubernetes Secret object by hand, and then prove the access control is what's actually gating it. Put a secret value into a Key Vault, enable the Key Vault CSI driver add-on, and mount that secret into a Pod as a file so the container can read it live from the vault. Then deliberately break it: revoke the add-on identity's access to the vault, force the Pod to be recreated, and confirm from the Pod's own status that it now fails to start with an access/authorization error rather than any image or scheduling problem — a useful contrast with the ImagePullBackOff authentication failures you diagnosed back in module 03 (conceptually building on that module's "which identity is allowed to do what" thinking). Restore access, confirm the mount succeeds again, then clean up: delete the test Pod and its SecretProviderClass, and remember Key Vault's soft-delete means a deleted vault may linger unless you purge it.

Common mistakes & troubleshooting

• Enabling Azure AD RBAC and then locking yourself out. Always bind at least one role (ideally an admin-equivalent one) to your own user identity before relying solely on Azure AD auth, or you can end up authenticated but authorized for nothing.
• Confusing Kubernetes-native RBAC objects with Azure RBAC for Kubernetes Authorization. If you enabled --enable-azure-rbac, permissions are managed via az role assignment create against built-in roles like "Azure Kubernetes Service RBAC Reader" — applying a Kubernetes RoleBinding YAML won't have the effect you expect in that mode. Know which mode your cluster is in.
• Forgetting the access policy step for Key Vault. The CSI driver add-on being "enabled" doesn't imply it can read your specific vault — it needs its identity explicitly granted get/list on secrets via az keyvault set-policy (or an Azure RBAC role assignment on the vault, depending on the vault's permission model).
• Treating Key Vault-mounted secrets as fire-and-forget. The CSI driver's default behavior mounts secrets as files at pod-start; some configurations need explicit rotation-poll settings to pick up Key-Vault-side changes without a pod restart — don't assume live updates happen automatically unless you've configured it.
• Cost pitfall: soft-deleted Key Vaults lingering. Key Vault's default soft-delete retention means a "deleted" vault can still exist (and in some configurations still incur minor charges/hold your unique name) for a retention window. If you're cleaning up permanently and your account has purge protection off, purge it explicitly rather than assuming delete alone is final.

Checkpoint quiz

Write down your answer to each question before expanding it — checking without attempting first is the single easiest way to fool yourself into thinking you've learned this.

1. What's the difference between plain Kubernetes RBAC and Azure AD-integrated Kubernetes RBAC?
2. What's the difference between Azure AD-integrated RBAC (still using RoleBinding YAML) and Azure RBAC for Kubernetes Authorization (--enable-azure-rbac)?
3. Why is pulling a secret from Key Vault via the CSI driver generally preferable to a plain Kubernetes Secret for sensitive values?
4. What two things does the Key Vault CSI driver's managed identity need before it can mount a secret into a pod?
5. What real risk do you run by enabling Azure AD RBAC without first binding a role to your own identity?
6. What does Key Vault's soft-delete behavior mean for cleanup, cost-wise?

Cumulative review

Closed-book. Don't reopen earlier modules while attempting these — the point is to find out what actually stuck.

1. You expose two apps to the internet through one Ingress, put an HPA on one of them, and drive load until the Cluster Autoscaler adds a node. Explain how many public IPs this whole setup uses and why, and why the new node appearing does not change that IP count.
2. Three different failures all surface as a Pod that won't run correctly: an Ingress whose ADDRESS stays empty, a Pod stuck Pending during an HPA-driven scale-up, and a Pod that won't start because it can't mount a Key Vault secret. For each, name the layer at fault and the single command whose output points you at the real cause.
3. --max-count on the Cluster Autoscaler and verbose application logging under Container Insights are both described as "cost knobs" distinct from node/disk cost. Explain what each one actually bills you for and why each is easy to leave running unnoticed.
4. Your HPA won't scale under load and its target shows <unknown>. What's the most likely cause, and how does that same missing piece also affect whether the Cluster Autoscaler makes correct decisions?
5. Compare the three managed identities you've touched by module 07: the cluster's identity used for ACR pulls (module 03), the Key Vault CSI add-on's identity, and a user's Azure AD identity used for cluster access. For each, what grant makes it actually able to do its job?
6. You enable Azure AD-integrated RBAC on a cluster and immediately can't do anything even though login succeeds. What happened, and how does this failure mode differ conceptually from being unable to authenticate at all?
7. Container Insights and a Key Vault can both outlive an az group delete on the cluster's resource group. Explain why each can survive, and what you'd run during final cleanup to catch each one.
8. Walk the request path for a user hitting one of your apps through Ingress: from the public IP, to the ingress controller, to the backing Service type, to the Pod. Why is the backing Service a ClusterIP and not a LoadBalancer, and where would monitoring let you see this traffic historically rather than live?
9. You want to prove, after the fact, that a Pod OOM-killed or crash-looped last night and was then replaced. Why is kubectl logs --previous insufficient, and what module-06 capability answers the question instead?
10. Rank these by how quickly they react to a sudden traffic spike, fastest first, and say which two work together to fully absorb the spike: the HPA adding replicas, the Cluster Autoscaler adding a node, an Azure AD role assignment taking effect. Explain the one that's a distractor.

Next

08-cicd-github-actions-to-aks — automate building, pushing, and deploying to AKS instead of running every step by hand.