Azure Managed Identities: Scope Blob Storage and Key Vault Access
Technical review: 26 October 2026. Product names, licensing references and procedures reflect this review; check the linked documentation for your release.
A managed identity removes the need to store a conventional application password, but it does not choose its own authorization boundary. The application still needs the right role at the right resource scope. Storage access, secret retrieval and cryptographic operations are different capabilities and should be granted separately.
Identify the runtime identity
Confirm whether the application uses a system-assigned or user-assigned managed identity. Record the principal/object ID used for role assignments and, where the SDK needs it, the client ID used to select a user-assigned identity. They are not interchangeable fields.
Separate the deployment identity from the application’s runtime identity. A pipeline may need to update an application resource while the running app needs only a specific data operation. Sharing one broad identity across both tasks makes permission review and incident response harder.
Choose data roles deliberately
| Application requirement | Role family to evaluate |
|---|---|
| Read blob contents | Storage Blob Data Reader at the appropriate scope. |
| Create or update blobs | Storage Blob Data Contributor where those operations are required. |
| Read a secret value | Key Vault Secrets User under the RBAC permission model. |
| Use a cryptographic key | The appropriate Key Vault cryptographic role for the required key operations. |
Azure resource Contributor is not a general grant to every service’s data plane. Equally, do not assume a management role is harmless merely because a separate data role exists: some management permissions can enable alternate access paths. Review the complete effective grant, including inherited assignments.
Verify the resource’s authorization and network model
Check whether the vault uses Azure RBAC or the legacy access-policy model; an RBAC data-role recipe does not apply unchanged to a vault using access policies. Record the intended container, vault or key scope and the exact operation the application needs.
Role assignments do not bypass a storage firewall, private endpoint or broken DNS path. If the identity has the expected role but the application cannot connect, investigate transport and endpoint resolution separately. Allow for documented propagation and token behavior before repeatedly creating duplicate assignments.
Test from the actual application context
A successful portal test under your administrator account proves little about the app. Use the intended managed identity from the real runtime and test one representative allowed operation. Then check a resource or operation that should remain out of scope. Do not print secret values, access tokens or customer blob contents into shared logs.
- Save the original role-assignment inventory and the approved change scope.
- Grant only the required role, keeping deployment and runtime permissions separate.
- Confirm positive and negative tests using the intended identity.
- Record the assignment IDs, ownership and the rollback action.
When an application is retired, remove its obsolete grants and verify that no shared identity depends on them. If creating the role assignment itself is denied, inspect delegation conditions rather than changing the application’s authentication code. Least privilege is a verified capability boundary, not simply a role name containing the word “User.”
References
- Microsoft: managed identities overview
- Microsoft: authorize Blob Storage with Azure roles
- Microsoft: Key Vault RBAC permissions