AKS RBAC and Workload Identity

AKS RBAC is the combination of Kubernetes RBAC and Azure AD integration to control access to the AKS cluster itself and the resources within it. Kubernetes RBAC is a built-in authorization mechanism that governs who can do what within the cluster (e.g., create pods, read secrets, delete deployments). Azure AD integration allows you to use Azure AD as the identity provider for authentication, meaning users and groups from your Azure AD tenant can authenticate to the cluster using their existing credentials. This eliminates the need for separate Kubernetes user accounts and enables centralized identity management.

The purpose of AKS RBAC is to enforce the principle of least privilege: each user, group, or service account should have only the permissions necessary to perform their job. Without RBAC, any authenticated user could potentially perform any action, leading to security risks. The AZ-104 exam expects you to understand how to configure RBAC for AKS clusters, including enabling Azure AD integration, creating role bindings, and using ClusterRoles and Roles.

Authentication and authorization in AKS with Azure AD integration involves a two-step process:

Key components: - Role: A namespaced resource that defines a set of permissions (e.g., get, list, watch, create, delete) on resources (e.g., pods, services, secrets). - ClusterRole: A cluster-scoped resource that defines permissions across all namespaces or on cluster-scoped resources (e.g., nodes, persistent volumes). - RoleBinding: Grants the permissions defined in a Role to a user, group, or service account within a specific namespace. - ClusterRoleBinding: Grants the permissions defined in a ClusterRole to a user, group, or service account across the entire cluster.

For Azure AD integration, you must enable the --enable-aad flag when creating the AKS cluster (or update an existing cluster). You also need to specify the --aad-admin-group-object-ids parameter to grant cluster admin permissions to specific Azure AD groups. Without this, no users have any permissions initially.

Workload Identity is a feature that allows pods in AKS to authenticate to Azure AD and access Azure resources (e.g., Azure Storage, Azure SQL Database, Key Vault) without managing secrets. It is the recommended approach for pod identity in AKS, replacing the older AAD Pod Identity (now deprecated). Workload Identity uses Azure AD's federated identity credential feature: you create a user-assigned managed identity in Azure AD and configure a federated identity credential that trusts tokens issued by the cluster's OIDC issuer. Pods can then request an access token from Azure AD using their projected service account token (a Kubernetes-bound token).

This solves the problem of securely providing credentials to pods. Traditionally, you would store connection strings or keys in Kubernetes secrets, which are vulnerable to exposure. With Workload Identity, no secrets are stored; the pod uses its service account identity to obtain tokens dynamically.

- The OIDC issuer URL of the AKS cluster (e.g., https://eastus.oic.prod-aks.azure.com/...) - The subject identifier: a string that matches the Kubernetes service account's iss and sub claims. Typically, this is system:serviceaccount:<namespace>:<serviceaccount-name>. - The audience: usually api://AzureADTokenExchange or a custom value.

Enable Azure AD integration on an existing cluster:

az aks update -n <cluster> -g <rg> --enable-aad --aad-admin-group-object-ids <group-id>

Create a Role and RoleBinding:

# role-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

kubectl apply -f role-pod-reader.yaml

# rolebinding-pod-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: "user@contoso.com"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

kubectl apply -f rolebinding-pod-reader.yaml

Enable Workload Identity on a cluster:

az aks update -n <cluster> -g <rg> --enable-oidc-issuer --enable-workload-identity

Create a service account for Workload Identity:

# sa-workload.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    azure.workload.identity/client-id: "<managed-identity-client-id>"
    azure.workload.identity/use: "true"
  name: my-sa
  namespace: default

kubectl apply -f sa-workload.yaml

Verify Workload Identity token projection:

kubectl exec -it <pod-name> -- cat /var/run/secrets/azure/workload-identity/token

A financial services company runs a microservices application on AKS. Each microservice needs to read/write to a specific Azure SQL database. Using Workload Identity, they create a user-assigned managed identity for each microservice (e.g., order-svc-id, payment-svc-id). Each managed identity is granted the necessary permissions on the corresponding SQL database (e.g., db_datareader, db_datawriter). The service account for each pod is annotated with the respective client ID. This setup ensures that if a pod is compromised, only the specific database it accesses is at risk. The company also uses Azure RBAC to restrict the managed identities from accessing other resources. In production, they have 50 microservices, each with its own identity. They automate the creation of federated credentials using Terraform. A common issue is that developers forget to update the federated credential subject when they rename a namespace, causing authentication failures. They use Azure Policy to enforce naming conventions and audit that each service account has the correct annotations.

A DevOps team uses Azure DevOps to deploy to AKS. They need to grant the pipeline agent (running as a service principal) permissions to deploy pods to a specific namespace. They create an Azure AD group aks-deployers and add the service principal to it. They then create a RoleBinding in the target namespace that grants the group cluster-admin or a custom role with deploy permissions. The pipeline uses az aks get-credentials with the service principal to authenticate. This is more secure than using a static kubeconfig file. The team also uses Azure RBAC to restrict the service principal to only the AKS cluster (via Contributor role on the cluster). A common mistake is giving the service principal cluster-wide permissions when only a namespace is needed. The exam tests that you can configure Azure AD integration for non-admin users and assign least-privilege roles.

A media company stores secrets (e.g., API keys, certificates) in Azure Key Vault. Their AKS-hosted podcast processing application needs to access these secrets. They use Workload Identity with a user-assigned managed identity that has Key Vault Secrets User role on the vault. The pod's service account is annotated, and the application uses the Azure Identity SDK to fetch secrets at startup. They set up a federated identity credential for each environment (dev, test, prod) with different managed identities. In production, they have autoscaling pods that all share the same service account. This works because the federated credential subject is the same for all pods (same service account). However, if they need different permissions per pod, they must use separate service accounts. A pitfall is that the projected token is mounted as a file, and if the pod runs as non-root, the file permissions must allow reading. The mutating webhook sets the file to be readable by all users by default. They also set up alerts on Azure AD sign-in logs for failed token exchanges, which indicate misconfigured federated credentials.