Managed Identities for Azure Resources

Managed Identities for Azure Resources

Managed Identities for Azure Resources

Why Are Managed Identities Important?

One of the biggest security challenges in cloud computing is managing credentials. Developers and administrators often need to store secrets, connection strings, keys, and certificates in application code or configuration files to authenticate to various Azure services. This practice introduces significant security risks, including credential leakage, accidental exposure in source control repositories, and the operational overhead of rotating secrets manually.

Managed identities solve this problem by eliminating the need to manage credentials entirely. They provide an automatically managed identity in Azure Active Directory (Azure AD), now called Microsoft Entra ID, that applications can use to authenticate to any service that supports Azure AD authentication — without storing any secrets in code or configuration.

For the SC-300 (Microsoft Identity and Access Administrator) exam, managed identities are a critical topic under the Plan and Implement Workload Identities domain. Understanding them is essential for securing Azure workloads and implementing zero-trust principles.

What Are Managed Identities?

A managed identity is a special type of service principal in Azure AD (Microsoft Entra ID) that is automatically managed by Azure. When you enable a managed identity for an Azure resource, Azure creates an identity for that resource in the Azure AD tenant that the subscription trusts. The identity's lifecycle (creation, rotation of credentials, and deletion) is fully managed by Azure.

There are two types of managed identities:

1. System-Assigned Managed Identity
- Created as part of an Azure resource (e.g., a Virtual Machine, App Service, Azure Function, Logic App, etc.)
- Tied directly to the lifecycle of that resource
- When the resource is deleted, the system-assigned identity is automatically deleted
- Only that specific Azure resource can use this identity
- Each resource gets its own unique identity — it cannot be shared
- Enabled directly on the resource

2. User-Assigned Managed Identity
- Created as a standalone Azure resource in its own right
- Has an independent lifecycle — it is NOT tied to any single Azure resource
- Can be assigned to one or more Azure resources simultaneously
- Must be explicitly deleted when no longer needed; deleting the associated resource does NOT delete the identity
- Useful when multiple resources need the same identity and permissions, or when you want the identity to persist beyond the life of a resource

How Do Managed Identities Work?

The underlying mechanism involves the Azure Instance Metadata Service (IMDS) and Azure AD token issuance. Here is the step-by-step flow:

Step 1: Enable the Managed Identity
When you enable a managed identity (system-assigned or user-assigned) on an Azure resource, Azure Resource Manager (ARM) communicates with Azure AD to create a service principal for that identity.

Step 2: Azure AD Creates a Service Principal
Azure AD creates a service principal object in the tenant. For system-assigned identities, this service principal is directly linked to the Azure resource. For user-assigned identities, the service principal is linked to the standalone managed identity resource.

Step 3: Credential Management
Azure automatically provisions and rotates the credentials (certificates) associated with the managed identity. You never see, handle, or manage these credentials.

Step 4: Token Request
When your application code running on the Azure resource needs to access another Azure service (e.g., Azure Key Vault, Azure Storage, Azure SQL), it makes a call to the local Azure Instance Metadata Service (IMDS) endpoint at http://169.254.169.254/metadata/identity/oauth2/token. This endpoint is only accessible from within the Azure resource.

Step 5: Token Issuance
The IMDS endpoint uses the locally stored credentials to request an access token from Azure AD on behalf of the managed identity. Azure AD validates the request and issues an OAuth 2.0 access token.

Step 6: Access the Target Resource
The application presents the access token to the target Azure service. The target service validates the token and, if the managed identity has been granted the appropriate RBAC (Role-Based Access Control) role or permissions, grants access.

Key Points About How It Works:
- No secrets are stored in code, configuration, or environment variables
- Credential rotation is handled automatically by Azure
- Tokens are short-lived and issued on demand
- The IMDS endpoint is a non-routable address, accessible only from within the Azure resource
- Managed identities work with any service that supports Azure AD authentication

Supported Azure Services

Managed identities can be enabled on many Azure resources, including but not limited to:
- Azure Virtual Machines and VM Scale Sets
- Azure App Service and Azure Functions
- Azure Logic Apps
- Azure Data Factory
- Azure Kubernetes Service (AKS)
- Azure API Management
- Azure Container Instances
- Azure Automation
- Azure Arc-enabled servers

Managed identities can be used to authenticate to services such as:
- Azure Key Vault
- Azure Storage (Blob, Queue, Table)
- Azure SQL Database
- Azure Resource Manager
- Azure Service Bus
- Azure Event Hubs
- Microsoft Graph API
- And any other service supporting Azure AD authentication

Assigning Permissions to Managed Identities

After creating a managed identity, you must grant it the appropriate permissions using Azure RBAC or access policies (depending on the target service). For example:
- To allow a managed identity to read secrets from Azure Key Vault, you assign a Key Vault access policy or the Key Vault Secrets User RBAC role
- To allow a managed identity to read from Azure Blob Storage, you assign the Storage Blob Data Reader role
- To allow a managed identity to query Azure SQL, you create a contained database user mapped to the identity

Comparing System-Assigned vs. User-Assigned Managed Identities

System-Assigned:
- Created with the resource, deleted with the resource
- One-to-one relationship with the resource
- Ideal for workloads contained within a single resource
- Simpler to set up for single-resource scenarios
- Identity is unique per resource

User-Assigned:
- Created independently as a standalone resource
- Can be shared across multiple resources (many-to-many relationship)
- Ideal for workloads that span multiple resources or need a shared identity
- Persists independently of the resources it is assigned to
- Must be explicitly managed and deleted
- Created in a resource group and can be assigned to resources across resource groups

Common Scenarios and Use Cases

Scenario 1: An Azure VM needs to retrieve secrets from Azure Key Vault. Enable a system-assigned managed identity on the VM, grant it the appropriate Key Vault access policy, and the application on the VM can retrieve secrets without any stored credentials.

Scenario 2: Multiple Azure Functions need to write to the same Storage Account. Create a user-assigned managed identity, assign the Storage Blob Data Contributor role, and attach the identity to all the Function Apps.

Scenario 3: An application running in Azure App Service needs to query Microsoft Graph to read user profiles. Enable a managed identity, grant it the required Microsoft Graph API permissions (app-level permissions via Azure AD), and use the identity to authenticate.

Managed Identities vs. Other Workload Identity Options

- Service Principals (App Registrations): Require manual credential management (client secrets or certificates). Managed identities are preferred when the workload runs on Azure.
- Managed Identities: No credential management, automatic rotation, and simpler operations. Limited to Azure-hosted resources.
- Workload Identity Federation: Used for external workloads (e.g., GitHub Actions, Kubernetes outside Azure) that need to authenticate to Azure AD without secrets using federated tokens.

Limitations of Managed Identities

- Managed identities can only be used by Azure resources; they cannot be used from on-premises servers or non-Azure environments (unless using Azure Arc)
- Not all Azure services support managed identities (though coverage is expanding)
- Cross-tenant scenarios are not supported — the managed identity exists in the same tenant as the Azure resource
- Moving a resource with a system-assigned managed identity to a different subscription or tenant requires disabling and re-enabling the identity
- There is a propagation delay when assigning RBAC roles to managed identities; it can take several minutes for permissions to take effect

---

Exam Tips: Answering Questions on Managed Identities for Azure Resources

Tip 1: Know the Two Types and When to Use Each
The SC-300 exam frequently tests your ability to choose between system-assigned and user-assigned managed identities. Remember: if the question describes a single resource that needs its own identity with a lifecycle tied to the resource, the answer is system-assigned. If the question involves multiple resources sharing the same identity or an identity that must persist beyond resource deletion, the answer is user-assigned.

Tip 2: Managed Identity = No Secrets in Code
If a question asks about the most secure or best practice way to authenticate an Azure resource to another Azure service, managed identities are almost always the correct answer over service principals with client secrets or certificates.

Tip 3: Understand the Permission Assignment
Enabling a managed identity alone does NOT grant it access to anything. You must explicitly assign RBAC roles or access policies. If a question describes a scenario where a managed identity is enabled but cannot access a resource, look for missing role assignments.

Tip 4: Lifecycle Matters
System-assigned identities are automatically deleted when the resource is deleted. User-assigned identities persist independently. Questions may test this by asking what happens to the identity after a resource is deleted.

Tip 5: Watch for Cross-Tenant and Migration Scenarios
If a question involves moving resources across subscriptions or tenants, remember that system-assigned managed identities do not transfer and must be reconfigured. This is a common exam trap.

Tip 6: Azure Instance Metadata Service (IMDS)
Understand that managed identities obtain tokens via the IMDS endpoint (169.254.169.254). This is a local, non-routable address. If a question asks how managed identities acquire tokens, the answer involves IMDS, not direct Azure AD calls from the application.

Tip 7: Managed Identity vs. Service Principal
A managed identity IS a service principal — but one that is fully managed by Azure. Do not confuse them. If the exam asks you to choose between creating an app registration with a client secret versus a managed identity for an Azure-hosted workload, always prefer the managed identity.

Tip 8: Supported Services
Know the most commonly tested services that support managed identities: VMs, App Service, Functions, Logic Apps, AKS, and Data Factory. Also know target services like Key Vault, Storage, and SQL Database.

Tip 9: Principle of Least Privilege
When assigning roles to managed identities, always choose the most restrictive role that meets the requirements. For example, use Storage Blob Data Reader instead of Contributor if only read access is needed. The exam tests for least-privilege role selection.

Tip 10: Read the Question Carefully for Keywords
Look for keywords like "without storing credentials," "automatically managed," "shared across multiple resources," "deleted when the resource is deleted," and "minimize administrative effort." These are strong indicators that the answer involves managed identities and help you determine which type to select.

Tip 11: Microsoft Graph Permissions
For scenarios where a managed identity needs Microsoft Graph permissions (e.g., reading users, groups), remember that you assign application permissions to the managed identity's service principal using PowerShell or the Azure CLI — this cannot be done through the Azure portal's app registration UI for managed identities. This is a nuanced point that may appear on the exam.

Summary for Exam Success:
Managed identities are a cornerstone of secure workload identity management in Azure. For the SC-300 exam, focus on understanding the difference between the two types, when to use each, how permissions are assigned, and why managed identities are preferred over manual credential management. Always think about security best practices, lifecycle management, and the principle of least privilege when evaluating answer choices.