Hello! Welcome to the next lesson in our journey to master the AZ-204 certification material.
In our last session, we successfully secured our application by retrieving secrets from Azure Key Vault programmatically. A key component of that solution was the DefaultAzureCredential class, which seamlessly authenticated you during local development. We ended with a crucial question: How does an application authenticate itself when it's deployed to Azure without a developer logged in?
Today, we answer that question by exploring Managed Identities. This is a foundational concept for building secure, credential-less applications in Azure. Our specific goal is to describe the difference between system-assigned and user-assigned managed identities. Understanding this distinction is vital for designing secure and maintainable cloud solutions.
1. The Problem: Credential-Free Authentication
Before diving into the types of managed identities, let's first solidify why they exist. When an application running in Azure (like an App Service or a VM) needs to access another Azure resource (like a Key Vault or Storage Account), it must authenticate itself. The traditional approach involved embedding credentials like connection strings or service principal secrets within the application's configuration. As we've discussed, this poses significant security risks and management overhead.
Managed identities solve this problem by providing an identity for Azure resources themselves within Microsoft Entra ID, allowing them to authenticate to services that support Entra ID authentication.
To set the stage, let's watch a short clip that perfectly frames this challenge.
Microsoft Azure Managed Identity Deep Dive
This video from John Savill's Technical Training, titled 'Microsoft Azure Managed Identity Deep Dive', begins by explaining the core problem that managed identities are designed to solve.
Watch from 00:20 to 02:35. Focus on the 'chicken and egg' problem described: even to get a secret from Azure Key Vault, your application first needs a secret to authenticate to Key Vault. This is the fundamental dilemma that managed identities resolve.
At its core, a managed identity is a special type of service principal in Microsoft Entra ID. However, unlike regular service principals, their lifecycle and credentials are automatically managed by Azure, freeing you from this responsibility.
2. The Two Flavors of Managed Identity
Managed identities come in two types, each suited for different scenarios. To introduce them, let's use a simple analogy.
Now, let's get the formal definitions for these two types. The official Microsoft Learn documentation provides the clearest and most concise explanation.
Managed identities for Azure resources - Microsoft Learn
The article 'Managed identities for Azure resources' on Microsoft Learn provides the foundational definitions for both identity types.
Please read the section titled 'Managed identity types'. As you read, pay close attention to the descriptions of System-assigned and User-assigned identities, specifically focusing on how they are created, their lifecycle, and their relationship with Azure resources.
3. Comparing System-Assigned and User-Assigned Identities
Having read the definitions, let's crystallize the differences. The most effective way to compare them is side-by-side.
The Microsoft Learn article you just reviewed contains a perfect summary table. Let's focus on it.
Managed identities for Azure resources - Microsoft Learn
Let's revisit the same Microsoft Learn article, this time focusing on the comparison table.
Study the table under the section 'Differences between system-assigned and user-assigned managed identities'. This table directly addresses our learning outcome by breaking down the comparison by creation, lifecycle, sharing, and common use cases.
To reinforce this, here is a summary of those key distinctions:
| Property | System-Assigned Managed Identity | User-Assigned Managed Identity |
|---|---|---|
| Creation | Enabled directly on an Azure resource. | Created as a standalone Azure resource. |
| Lifecycle | Tied to the resource. Deleted automatically when the parent resource is deleted. | Independent. Must be explicitly deleted. |
| Sharing | Cannot be shared. Tied 1-to-1 with a single resource. | Can be shared. Can be assigned to multiple resources. |
| Use Case | A workload contained within a single Azure resource (e.g., one specific VM needs access to a storage account). | A group of resources needs the same permissions (e.g., a fleet of VMs in a scale set or multiple App Services in a web farm need to access the same database). |
4. When to Use Which? Best Practices
The choice between system-assigned and user-assigned identity depends on your application's architecture and security requirements.
-
Choose System-Assigned for Simplicity: If you have a single resource that needs its own identity, and you want that identity's permissions to be created and destroyed along with the resource, a system-assigned identity is the simplest choice.
-
Choose User-Assigned for Scalability and Pre-Authorization: If you have multiple resources that require the same set of permissions, a user-assigned identity is far more efficient. You grant permissions to the single user-assigned identity once, and then assign that identity to all your resources. This dramatically reduces administrative overhead. It's also useful when you need to set up permissions before the application resources are even deployed.
Let's watch one more video segment to hear these concepts explained and see the relationships illustrated.
Microsoft Azure Managed Identity Deep Dive
John Savill's video provides a clear, verbal walkthrough that complements the text-based documentation we've just read.
Please watch the following segments: 10:14 - 14:21: This section covers the system-assigned identity, its linked lifecycle, and how it's a 1-to-1 mapping to a resource. 14:21 - 18:13: This section explains the user-assigned identity as a separate resource with its own lifecycle and how it enables a many-to-many relationship. 45:46 - 47:03: This is a great summary of best practices, explaining when to choose one type over the other.
A final key point is that an Azure resource can have one system-assigned identity and multiple user-assigned identities at the same time. This provides flexibility for complex scenarios where a resource might need a specific permission for itself, in addition to a set of shared permissions.
Conclusion
In this lesson, you've learned the crucial differences between the two types of managed identities, which is a core security concept for any Azure developer.
Key Takeaways:
- System-Assigned Identity:
- Tied directly to an Azure resource.
- Lifecycle is shared: when the resource is deleted, the identity is deleted.
- Represents a 1-to-1 relationship.
- Ideal for simple, self-contained workloads.
- User-Assigned Identity:
- A standalone, independent Azure resource.
- Lifecycle is separate: it must be deleted explicitly.
- Can be assigned to multiple resources, enabling a many-to-many relationship.
- Best for scalable solutions (like web farms) or when you need to grant permissions before resources are created.
Next Steps
Now that you understand the theory, it's time to put it into practice. In our next lesson, we will enable a system-assigned managed identity for an Azure App Service. You'll see firsthand how to create this identity and lay the groundwork for it to securely access other Azure services, like the Key Vault we worked with previously, without a single credential in your code.