Managed Identities

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 federated 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 manages 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 identities, their lifecycle is directly correlated to the lifecycle of the resource itself. If the Virtual Machine is deleted, the system-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 needs 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 creating 5 separate system-assigned identities, 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 identify 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.

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.