Azure: choose managed identity over connection strings, and know when you cannot

Not specified by the original author.

TL;DR

Delete the connection string from config. Decision rules: Use managed identity (system-assigned where the resource supports it, user-assigned when several resources share one identity or you need pre-provisioning) when: - The caller runs on Azure (App Service, Functions, AKS, VMs, Container Apps). Delete the app, the identity is gone, and role assignments referencing it dangle.

When to use

You are seeing this: The platform injects the identity; there is nothing to store. - The target SDK supports Entra auth (all current Azure SDKs do via DefaultAzureCredential / azidentity). - You want audit: Entra sign-in logs show which identity accessed what, unlike a shared key. Use this skill when you run into "Azure: choose managed identity over connection strings, and know when you cannot".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Decision rules:

Use managed identity (system-assigned where the resource supports it, user-assigned when several resources share one identity or you need pre-provisioning) when:

• The caller runs on Azure (App Service, Functions, AKS, VMs, Container Apps). The platform injects the identity; there is nothing to store.
• The target SDK supports Entra auth (all current Azure SDKs do via DefaultAzureCredential / azidentity).
• You want audit: Entra sign-in logs show which identity accessed what, unlike a shared key.

Keep a connection string or key only when:

• Running against a local emulator (Azurite, Cosmos DB emulator) that has no Entra.
• A third-party tool cannot do Entra auth (some BI tools, legacy drivers).
• Break-glass access where identity infra itself might be down.

Migration path that does not break prod:

1. Create the managed identity and grant the data-plane roles (Storage Blob Data Contributor, Key Vault Secrets User, etc.) while the old connection string still works.
2. Deploy code that tries identity first and falls back to the connection string, behind a flag.
3. Flip the flag in staging, verify, then prod.
4. Delete the connection string from config. If something still needed it, step 2's fallback would have logged it.

Traps:

• System-assigned identity dies with the resource. Delete the app, the identity is gone, and role assignments referencing it dangle. User-assigned survives and is better for anything you might recreate.
• One identity per trust boundary. Do not share a single user-assigned identity across unrelated apps; a compromised app inherits all its roles.
• Local dev gap. Managed identity does not exist on your laptop. DefaultAzureCredential's dev-tool steps (az login etc.) bridge this; make sure local runs use those and prod uses the managed identity step, which is exactly what the chain order gives you for free.

Proactive skill. Managed identity guidance synthesized from current Entra managed-identities docs. Evidence: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview