Azure Compute VMs cannot access storage accounts using managed identity despite correct RBAC role assignments

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

Our Azure VMs with system-assigned managed identities are failing to authenticate when trying to access blob storage accounts. The application is supposed to start automatically and pull configuration files from storage, but it’s throwing 403 Forbidden errors.

Here’s the error we’re seeing in application logs:


Status: 403 (This request is not authorized)
ErrorCode: AuthorizationPermissionMismatch
Server failed to authenticate the request

The VMs have system-assigned managed identity enabled, and we’ve assigned the “Storage Blob Data Reader” role at the storage account level. The application code uses DefaultAzureCredential which should automatically pick up the managed identity. We’ve verified the role assignment exists in the IAM blade, but the authorization still fails during application startup. Is there something we’re missing with the RBAC configuration or managed identity setup?

2

Based on your description, you’re dealing with a combination of RBAC and network security issues. Let me walk through the complete solution:

1. Managed Identity Configuration: First, verify the managed identity is properly configured and the application is using it correctly. Run this from the VM to confirm identity access:


curl 'http://169.254.169.254/metadata/identity/oauth2/token?api-version=2018-02-01&resource=https://storage.azure.com/' -H Metadata:true

This should return an access token. If it fails, the managed identity isn’t properly enabled.

2. RBAC Role Assignment: You need “Storage Blob Data Reader” role, but verify the scope is correct:

  • Navigate to Storage Account → Access Control (IAM) → Role assignments
  • Confirm the system-assigned identity from your VM is listed
  • Verify the role is assigned at storage account level or specific container level
  • If you only need specific containers, assign at container scope for better security

Important: The role must be “Storage Blob Data Reader” (data plane) not “Reader” (management plane). These are different permission sets.

3. Storage Account Firewall Rules: This is likely your primary issue. When “Selected networks” is enabled, you must explicitly allow access:

Option A - Service Endpoints (Recommended):

  • Enable service endpoint on VM subnet: Subnet → Service endpoints → Add Microsoft.Storage
  • Add subnet to storage firewall: Storage Account → Networking → Firewalls and virtual networks → Add existing virtual network
  • Select your VNet and subnet

Option B - Trusted Azure Services: Enable the exception: Storage Account → Networking → Exceptions → Check “Allow Azure services on the trusted services list to access this storage account”

This allows managed identity authentication to bypass firewall rules.

4. Storage Access Validation: After configuring network rules, test access from the VM:


az storage blob list --account-name <storage-account> --container-name <container> --auth-mode login

If this works but your application still fails, the issue is in your application code’s credential chain.

5. Application Startup Considerations: For application startup scenarios, implement retry logic. Managed identity token acquisition can occasionally fail during VM startup when the identity service isn’t fully initialized. Add exponential backoff:

  • Initial retry after 2 seconds
  • Subsequent retries with 5, 10, 30 second delays
  • Maximum 5 retry attempts

6. Monitoring and Troubleshooting: Enable storage account diagnostic logs to see detailed authentication failures:

  • Storage Account → Diagnostic settings → Add diagnostic setting
  • Enable StorageRead, StorageWrite logs
  • Send to Log Analytics workspace
  • Query for 403 errors to see exact failure reasons

Complete Checklist:

  • [ ] System-assigned managed identity enabled on VM
  • [ ] “Storage Blob Data Reader” role assigned to managed identity
  • [ ] Role assignment propagated (wait 10 minutes after assignment)
  • [ ] Service endpoint enabled on VM subnet
  • [ ] VM subnet added to storage account firewall rules
  • [ ] “Allow trusted Azure services” exception enabled
  • [ ] Application using correct credential provider (DefaultAzureCredential)
  • [ ] Retry logic implemented for startup scenarios

The combination of service endpoints and the trusted services exception should resolve your 403 errors. The firewall rules are almost certainly blocking your managed identity authentication attempts despite correct RBAC configuration.

3

First thing to check - does your storage account have firewall rules configured? If you’ve enabled “Selected networks” in the storage account networking settings, you need to explicitly allow your VM’s subnet or add the VM’s public IP to the firewall exceptions. Managed identity authentication still needs network-level access to work. Even with correct RBAC roles, the firewall will block the requests before authentication happens.

4

Don’t forget to check if your storage account has the “Allow Azure services on the trusted services list” option enabled. This is under Networking → Firewalls and virtual networks → Exceptions. When enabled, Azure services using managed identities can bypass the firewall rules. However, this only works if the service is on Microsoft’s trusted services list, which includes Azure VMs. It’s a quick workaround while you properly configure service endpoints.

5

I ran into this exact issue last month. The problem was role assignment propagation delay. Even though the role shows up in the IAM blade immediately, it can take 5-10 minutes for Azure to fully propagate the RBAC permissions across all storage endpoints. Try waiting a bit longer after assigning the role, or restart your application. Also verify you’re assigning the role to the correct managed identity - if you have both system-assigned and user-assigned identities, make sure you’re not mixing them up.

6

The role has been assigned for over 24 hours, so propagation shouldn’t be the issue. I checked the networking settings - we do have firewall rules enabled with “Selected networks” configured. I see options to add virtual networks or IP ranges. Should I add the VM’s subnet to the allowed networks, or is there a better approach using service endpoints?

7

For production scenarios, definitely use service endpoints or private endpoints rather than adding individual IPs. Enable Microsoft.Storage service endpoint on your VM’s subnet, then add that subnet to the storage account firewall’s virtual network rules. This creates a secure connection path that doesn’t go over the public internet. Service endpoints are free and work well with managed identities. Just make sure the subnet delegation doesn’t conflict if you’re using other Azure services on the same subnet.