You can develop, but can you develop for the cloud? Harness your development skills and learn how to create robust solutions for Microsoft Azure, aiming for your Microsoft Certified: Azure Developer Associate certification!
Gauge your current knowledge
Gauge your current knowledge
Managed identities give Azure resources a way to prove their identity to other services without storing passwords or secrets. They act as workload identities that remove the risk of leaking credentials from application code. Two types exist, and the choice depends on how the identity’s lifecycle and scope fit the workload.
A system-assigned managed identity is created directly on a single Azure resource, such as a virtual machine or an App Service. Its lifecycle is tied to that resource: when the resource is deleted, Azure automatically deletes the identity. This creates a one-to-one relationship, and the identity’s name usually matches the resource name. Use this type when the identity should exist only as long as the resource exists and does not need to be shared.
A user-assigned managed identity is created as a standalone Azure resource with its own independent lifecycle. It can be assigned to multiple Azure services at once, making it reusable across different resources. Because it is a separate resource, you must manually delete it even after the associated compute resources are removed. User-assigned identities reduce management overhead by using fewer role assignments and allow you to create and authorize the identity before deploying the compute resource. Choose this type when multiple resources need the same permissions or when you want to separate identity management from resource lifecycle.
Managed identities provide a secure, automated way for Azure compute resources to authenticate to services that support Microsoft Entra ID, such as Azure Key Vault or Storage Accounts. Developers never handle secrets, keys, or certificates because Azure manages the identity and token rotation behind the scenes.
To set this up, you first enable a managed identity on a supported Azure compute resource, such as Azure App Service, Azure Functions, or Azure Virtual Machines. You then grant the identity access to the target resource by assigning the appropriate RBAC role. For example, assign the Storage Blob Data Contributor role to allow read and write access to a storage account. This ensures the principle of least privilege is followed, granting only the permissions needed for the task.
In application code, you use the Azure Identity client library to authenticate automatically. The DefaultAzureCredential class in .NET, Java, or Python tries a chain of credential sources until it finds one that works. When the app runs in Azure, it discovers the configured managed identity and acquires tokens without any hardcoded credentials. The library handles token caching and renewal, so the code focuses on business logic rather than authentication details.
Programmatic token acquisition is the process by which an application automatically obtains an access token from Microsoft Entra ID to access Azure resources. The Azure Identity client library provides the tools to do this across different environments and languages.
The DefaultAzureCredential class is a high-level abstraction that simplifies authentication by trying a chain of credential types in order. In local development, it uses credentials from developer tools like the Azure CLI or Visual Studio. When deployed to Azure, it automatically discovers and uses the configured managed identity. You can customize the chain by setting environment variables such as AZURE_CLIENT_ID, AZURE_TENANT_ID, and AZURE_CLIENT_SECRET for service principals, or by using the builder pattern to specify a user-assigned identity’s client ID.
For applications running only in Azure, the ManagedIdentityCredential class provides a secretless authentication experience. It directly interacts with the Azure Instance Metadata Service (IMDS) endpoint or the IDENTITY/MSI endpoint to obtain tokens. This credential type is ideal for Virtual Machines, App Service, or Azure Kubernetes Service (AKS) that have managed identity enabled. The library handles the entire token acquisition, caching, and refresh process, so developers never need to write token-handling code.
Managed identities prove who an Azure resource is using Microsoft Entra ID, and Azure Role-Based Access Control (RBAC) defines what that identity is allowed to do. This combination provides credential-free authorization that eliminates the need for passwords or manual keys.
Both system-assigned and user-assigned identities can be given RBAC roles. To authorize access, you assign a specific role to the managed identity’s principal ID. For example, you might assign the Storage Blob Data Contributor role to a virtual machine’s identity so it can read and write blobs. This step connects the identity to the target resource and defines the exact actions allowed. The same principle applies to Azure Key Vault, where you can use an access policy instead of a role assignment.
Always follow the principle of least privilege when assigning roles. Grant only the minimum permissions required for the task. For instance, if an app only needs to read files, do not give it Owner or Contributor roles. Limiting access reduces the potential damage if the identity is ever compromised. Developers can use the Azure Identity library and DefaultAzureCredential to request tokens in code, and those tokens are then checked against the assigned RBAC roles to authorize access to services like Azure SQL or Cosmos DB.
Configuring managed identities involves enabling them on Azure resources and then granting those identities access to other resources. Azure manages the identity credentials automatically, so there are no secrets to rotate or store.
You enable managed identities through the Azure portal, CLI, PowerShell, or ARM templates. In the portal, navigate to the resource’s Identity blade, switch the Status to On, and click Save. With Azure CLI, use commands like az webapp identity assign for App Services or az vm identity assign for VMs. ARM templates include an "identity" property with "type": "SystemAssigned" or "UserAssigned". After enabling, the identity’s principalId and tenantId appear in the resource metadata. You can also enable both types on a single service for advanced scenarios.
After the identity is enabled, grant it access to target resources using RBAC role assignments or service-specific policies. In the portal, go to Access control (IAM) > Add role assignment, choose Managed identity, and select the identity. CLI commands like az role assignment create --assignee --role --scope automate the process. For Key Vault, you may instead use an access policy tied to the identity.
In code, use the Azure Identity library to authenticate. For .NET, use DefaultAzureCredential with ManagedIdentityClientId set for user-assigned identities. Java and Node.js use DefaultAzureCredentialBuilder().managedIdentityClientId(...), and Python passes managed_identity_client_id to DefaultAzureCredential. At runtime, calls to the metadata endpoint fetch tokens, and the SDK handles caching and renewal.
StudyCerts
StudyCerts