In the previous lesson, we learned that applications can use Service Principals to authenticate to Microsoft Entra ID.
A service principal can authenticate using three types of credentials:
- a client secret
- a certificate
- a federate credential
However, these credentials need to be kept safe and managed.
Client secrets expire, and so do certificates.
If a credential is stored inside source code or an unsecured configuration file, it might become exposed.
What if an application could authenticate to Azure without you creating, storing, or rotating any credentials?
That’s what Managed Identities allow you to do.
What is a Managed Identity?
A managed identity is a special type of service principal.
When you create a managed identity, Azure creates a corresponding service principal in Entra ID.
The main difference is that Azure fully managed the credentials for it under the hood, so that you don’t touch client secrets, certificates, or federated credentials.
Managed Identities come in two flavours, depending on the level of control you need and the lifecycle you want them to have: system-assigned and user-assigned.
What is a System-Assigned Managed Identity?
A system-assigned managed identity is created directly on an Azure resource.
System-assigned managed identities are created automatically when you “enable” them on a supported Azure resource.
For example, you can enable a system-assigned managed identity on an Azure Virtual Machine.
For system-assigned managed identites, their lifecycle is directly correlated to the lifecycle of the resource itself. If the Virtual Machine is deleted, the systme-assigned managed identity linked to it is also deleted.
System-assigned managed identities belong to only one Azure resource and cannot be shared among multiple resources, and that’s by design.
For example, if you have three Virtual Machines, you can enable system-assigned managed identities for all three, and those will be three separate managed identities.
What is a User-Assigned Managed Identity?
A user-assigned managed identity is created independently of an Azure resource.
It does not belong to one specific Virtual Machine, App Service, or any other supported resource.
You create a user-assigned managed identity and assign that identity to one or more Azure resources.
For example, you create the identity production-host-app and assign it to three App Services:
- zta-app-service-01
- zta-app-service-02
- zta-app-service-03
The lifecycle of the user-assigned identity is independent of the resources that uses it. If you delete zta-app-service-03 , the user-managed identity will still exist.
When should you use system-assigned vs user-assigned?
System-assigned managed identities are useful when:
- Only one Azure resource needs to use the identity
- The identity should be deleted when the Azure resource is deleted
- You want the least amount of overhead to manage the identity
A good use for a system-assigned managed identity is a Virtual Machine that needs to read secrets from a Key Vault. You can enable a system-assigned identity on the Virtual Machine, and assign it the required RBAC role to access the secrets in the Key Vault.
User-assigned managed-identities are useful when:
- Multiple Azure resources need to use the same identity
- The identity needs to exist before the Azure resources are created
- The identity neesd to exist after the Azure resources are deleted
- You want to manage the identity separately from Azure resources
A good use for a user-assigned managed identity is 5 Virtual Machines that run the same application and need to read data from a Storage Account.
Instead of creeating 5 separate system-assigned identites, you can create one user-assigned managed identity and assign it to all 5 VMs. Lastly, assign the necessary Azure RBAC role to the user-assigned identity to be able to access the Storage Account.
Managed Identity vs Service Principal
Both a managed identity and a service principal are used to identity software applications.
In fact, a managed identity under the hood is still a service principal. The main difference is who is responsible for managing the credentials.
Feature
Managed Identity
Regular Service Principal
Can receive Azure RBAC roles
Yes
Yes
You manage the credentials
No
Yes
Azure rotates the credentials
Yes
No
Requires storing secrets in the application configuration
No
Most of the time
What to remember for your exam
- A managed identity is a service principal for which the credentials are managed by Azure automatically.
- A system-assigned managed identity belongs to only one Azure resource.
- A user-assigned managed identity can be shared by multiple Azure resources.
- Deleting an Azure resource also deletes the system-assigned managed identity tied to it.
- Deleting an Azure resource does not delete user-assigned managed identities linked to it.
What’s next?
Now that you have a strong foundation in Azure Identity, let’s move on to the next module, discussing Azure storage solutions.
