L12. Managed Identities and Workload Identity Federation

Managed Identities Overview

Managed identities provide an automatically managed identity in Entra ID for Azure resources. They eliminate the need to store credentials in code, configuration files, or key vaults. The identity lifecycle is managed by Azure.

System-Assigned vs User-Assigned

When to Use Each

System-assigned: Best for workloads that run on a single resource and need independent identities. Example: a single VM that needs to read from Azure Key Vault. User-assigned: Best for workloads that run on multiple resources and need a shared identity. Example: multiple VMs in a scale set that all need the same permissions to access a storage account. Exam tip: If a question describes multiple resources needing the same set of permissions, the answer is user-assigned managed identity. If the question describes a single resource with its own identity lifecycle, the answer is system-assigned.

How Managed Identities Work

1. Azure Resource Manager creates a service principal in Entra ID for the managed identity
2. The resource is configured with the identity (certificate credential is provisioned automatically)
3. The code running on the resource requests a token from the Azure Instance Metadata Service (IMDS) endpoint: http://169.254.169.254/metadata/identity/oauth2/token
4. Entra ID returns an access token
5. The code uses the token to access the target Azure service

Exam tip: The IMDS endpoint (169.254.169.254) is a link-local address only accessible from within the Azure resource. It cannot be reached from outside the VM, which prevents token theft from the network.

Assigning Permissions

Managed identities are granted access through Azure RBAC, just like user accounts:

az role assignment create \
  --assignee <managed-identity-object-id> \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Storage/storageAccounts/<account>

Workload Identity Federation

Workload identity federation enables external workloads (outside Azure) to access Azure resources without storing secrets. Instead of a client secret or certificate, the external workload presents a token from its own identity provider, and Entra ID trusts that token based on a configured trust relationship.

Common Scenarios

• GitHub Actions: A GitHub workflow accesses Azure resources using a federated credential instead of storing an Azure secret in GitHub
• Kubernetes (non-AKS): Pods in external Kubernetes clusters authenticate to Azure
• Google Cloud/AWS: Workloads in other clouds access Azure resources

Configuration Steps

1. Create an app registration in Entra ID
2. Add a federated credential specifying the external IdP (issuer URL), subject, and audience
3. Grant the app registration RBAC permissions on Azure resources
4. Configure the external workload to request tokens from its IdP and exchange them for Entra ID tokens

Exam tip: Workload identity federation eliminates stored secrets entirely. No client secret or certificate is needed. The trust is based on the external IdP's token, validated by the issuer, subject, and audience fields. This is the most secure approach for cross-cloud or CI/CD scenarios.

Managed Identity for Azure Services

Common Azure services that support managed identities: Virtual Machines, App Service, Functions, Logic Apps, Container Instances, AKS, Data Factory, and many more. Not all services support user-assigned identities, so check compatibility for specific scenarios.