Introduction
Hardening data plane access for a storage account is a common practice to enhance security. However, when using Azure resources with virtual network (VNET) integration or accessing storage endpoints from private IPs or other tenants, authorization errors can occur if the source is not properly whitelisted. This article explores common scenarios that lead to such errors and provides actionable resolutions.
Common Authorization Error Scenarios
Scenario 1: Access from Another Region
When the source making the call originates from a different Azure region, the issue can typically be resolved by adding the source’s public IP address to the storage account firewall.
Scenario 2: Same Region Access Fails
Requests originating from the same Azure region often use Azure private IP addresses instead of public IPs. In this case, whitelisting public IPs will fail. Refer to Configure Azure Storage Firewalls and Virtual Networks for more details.
Scenario 3: Restricting Access to a Specific Subnet
If resources lack public IPs, but the client wishes to restrict access to a specific subnet, they may encounter issues due to visibility limitations. The storage account firewall might not display the target subnet, requiring manual whitelisting by someone with Contributor RBAC access or higher.
Scenario 4: Access from a Different Azure Tenant
When resources attempting to access the storage account belong to a different Azure tenant, additional steps are required to whitelist the source subnet.
Resolution Steps
Adding a Subnet from Another Tenant
To whitelist a subnet from a virtual network in a different Azure tenant, the VirtualNetworkResourceId parameter must be used. This involves specifying the subnet URI in the form:
/subscriptions/<subscription-ID>/resourceGroups/<resourceGroup-Name>/providers/Microsoft.Network/virtualNetworks/<vNet-name>/subnets/<subnet-name>
Example PowerShell Command
To fetch the subnet URI, use the following command:
$subnet = Get-AzVirtualNetwork -ResourceGroupName "myresourcegroup" -Name "myvnet" | Get-AzVirtualNetworkSubnetConfig -Name "mysubnet"
If the user lacks sufficient access to execute this command in the source tenant, they can retrieve the subnet URI by inspecting the JSON body of the VNET resource in Azure. This requires control plane READ access over the resource.
Enabling Storage Service Endpoint
Before whitelisting the subnet, ensure the Microsoft.Storage or Microsoft.Storage.Global service endpoint is enabled. This can be done using Azure PowerShell, CLI, or the Azure Portal. For step-by-step instructions, refer to Configure Azure Storage Firewalls and Virtual Networks.
Example Command for Whitelisting
Once the subnet URI is obtained, use the following command to add the network rule:
Add-AzStorageAccountNetworkRule -ResourceGroupName "myresourcegroup" -AccountName "mystorageaccount" -VirtualNetworkResourceId $subnet
Verification
To verify the connection, use the curl
command with a SAS token:
curl https://storageaccountname.blob.core.windows.net/container/hello.txt?<SAS token>
Tip:
- The
-v
flag in thecurl
command enables verbose output, which can help identify HTTP responses such as403 Forbidden
. Remove the flag for cleaner output.

Example below will show the subnet in the target storage account firewall

Tip: Highlighted warning is safe to ignore, this is tied to READ control plane access over the whitelisted subnet, data plane access will be allowed.
Additional Considerations
- Service Endpoint Enablement: Enabling the storage service endpoint may cause temporary connectivity interruptions. For more information, see Azure Virtual Network Service Endpoints.
- Private Endpoints: Private endpoints bypass firewall network rules as they rely on DNS and connectivity over the granted subnet. Refer to Use Private Endpoints – Azure Storage.
- Control Plane vs. Data Plane: Understanding the difference between control plane and data plane operations is crucial for troubleshooting. Learn more at Control Plane and Data Plane Operations.
Conclusion
Authorization errors when accessing Azure Storage endpoints often stem from misconfigured firewall rules or insufficient subnet visibility. By following the steps outlined above, you can effectively troubleshoot and resolve these issues, ensuring secure and seamless data plane access.