Using Managed Identities to Eliminate Hardcoded Credentials

Overview and What You Will Learn

In this lab, you will create both a System-Assigned and a User-Assigned Managed Identity, attach each to a different VM, and see how each identity type's lifecycle differs - one tied permanently to a single resource, the other reusable across several resources independently.

Why This Matters in Production

A developer at a fintech startup creates a traditional service principal with a client secret to let an application authenticate to Azure services, then has to store that secret somewhere, remember to rotate it before it expires, and worry about it leaking from a config file or log output. Managed Identity removes this entire category of concern - there is no secret to store, rotate, or leak, because none exists.

Core Principles

Azure offers two types of Managed Identity, and choosing between them depends on whether the identity's lifecycle should be tied to one specific resource or shared across several.

Both types eliminate the need to store any credential at all - the difference is purely about lifecycle and reusability, not about the underlying security model, which is identical for both.

Detailed Step-by-Step Practical Lab

1. Create a Resource Group and a VM with a System-Assigned Managed Identity:

2. Confirm the System-Assigned identity was created and tied to this specific VM:

3. Create a separate User-Assigned Managed Identity as its own independent resource:

4. Attach that same User-Assigned identity to two different VMs, demonstrating its reusability:

5. Confirm both VMs now share the same identity, unlike the System-Assigned example where each VM would have gotten its own unique identity:

Note

Both commands should show a reference to the same uai-shared-identity resource ID - confirming this identity is genuinely shared, rather than each VM getting its own separate identity the way System-Assigned would have created.

6. If vm-system-identity is deleted, its System-Assigned identity is automatically deleted along with it. If either shared VM is deleted, uai-shared-identity continues to exist independently, still usable by the remaining VM or future resources.

7. Clean up:

Production Best Practices & Common Pitfalls

Common Mistake

Creating a traditional service principal with a client secret for a workload running entirely on Azure compute (VMs, App Service, AKS), when Managed Identity would provide the same access with no credential to store, rotate, or leak at all.

Tip

Use User-Assigned Managed Identity when several resources need to share the exact same set of permissions - like an entire fleet of VMs all needing read access to the same Key Vault. Use System-Assigned when the identity's purpose is genuinely tied to one specific resource's lifecycle.

• Managed Identity only works for Azure resources calling other Azure services - it does not help an application running outside Azure (like on a developer's laptop) authenticate to Azure services, which still needs a different authentication method for local development.
• Granting a Managed Identity access still goes through normal RBAC. Creating the identity itself grants no permissions automatically - you still need to explicitly assign it a role scoped to whatever resource it needs to access.

Quick Reference & Troubleshooting Commands