Managed Identity Pattern Review Prompt
Review how an Azure workload authenticates to other services and replace secrets and account keys with the right managed-identity pattern, scoped to least privilege.
- Target user
- Cloud platform and application engineers eliminating secrets on Azure
- Difficulty
- Intermediate
- Tools
- Claude, ChatGPT, Cursor
The prompt
You are a senior Azure platform engineer who removes secrets for a living. You replace connection strings, account keys, and stored client secrets with managed identities, and you scope every role assignment to exactly what the workload needs. I will provide: - The workload — what it is (Function, App Service, AKS pod, VM, Container App), and where it runs — [WORKLOAD] - How it authenticates today — connection strings, account keys, SPN client secrets, SAS, etc. — [CURRENT_AUTH] - What it talks to — Storage, Key Vault, SQL, Service Bus, another API — and the operations it performs — [DOWNSTREAM_SERVICES] - Any existing identities — system-assigned, user-assigned, and current role assignments — [EXISTING_IDENTITY] - Constraints — multiple workloads sharing an identity?, cross-subscription?, federated workload identity needed? — [CONSTRAINTS] Your job: 1. **Choose the identity pattern** — system-assigned (one identity per resource, dies with it) vs user-assigned (shared across resources, survives recreation). Recommend user-assigned when multiple workloads or blue/green need the same identity, system-assigned for single-resource simplicity. For AKS, prefer Workload Identity (federated) over the deprecated pod-managed-identity. 2. **Map each downstream call to a role** — give the exact data-plane RBAC role per service (e.g. Storage Blob Data Reader, Key Vault Secrets User, Azure Service Bus Data Sender) scoped to the narrowest resource that works. No Owner, no Contributor for data access. 3. **Replace the secret** — show how the SDK picks up the identity (DefaultAzureCredential / ManagedIdentityCredential), and what secret/connection string gets deleted once the identity works. 4. **Migration order** — assign the identity and roles, switch the code/config to the credential, verify, then remove the old secret. Never delete the secret first. 5. **Flag over-grant and shared-identity risk** — call out any role broader than needed and any case where one identity shared across workloads widens blast radius. Output as: (a) the recommended identity type with rationale; (b) a table of downstream service -> exact role -> scope; (c) the `az identity` / `az role assignment create` commands; (d) the credential code snippet and the secret to retire; (e) a rollback note. Use only the services and operations I listed. Don't assign roles for services I didn't mention, and ask if the required data-plane operations are unclear.
Why this prompt works
The hardest part of going secretless on Azure is not the mechanics of managed identity — it is choosing the right pattern and scoping the roles correctly. This prompt makes both decisions explicit. It forces a choice between system-assigned and user-assigned identities based on real criteria (single resource versus shared across blue/green or multiple workloads) rather than defaulting to whichever the engineer used last time, and for AKS it steers toward Workload Identity instead of the deprecated pod-managed-identity that still lingers in old docs and tutorials.
What makes the output trustworthy is the insistence on mapping each downstream call to a specific data-plane RBAC role at the narrowest scope. The failure mode in real environments is not too few permissions but too many: an engineer grants Contributor at the resource group because it “just works,” and now a compromised workload identity can rewrite infrastructure. By requiring a service-to-role-to-scope table built from the actual operations the workload performs, the prompt produces least-privilege assignments instead of convenient over-grants.
The guardrails enforce the migration order that keeps this safe. Deleting the old secret before the identity is proven is the single most common way these migrations cause an outage, so the prompt requires assign-verify-switch-then-remove every time. Combined with the explicit call-out of over-broad roles and shared-identity blast radius, this turns a risky secret-removal project into a sequence of reversible, verifiable steps where the human always confirms the workload still works before anything is torn down.