Forum Discussion

miksingh's avatar
miksingh
Copper Contributor
Oct 12, 2021

Azure Storage - Private Link

Hi,

 

I was looking at Private Link for blob storage and I have some outstanding queries:

 

I setup private DNS and private link for blob storage, this gave me a DNS record similar to the following: xyz.privatelink.blob.core.windows.net, which had a private IP address (10.1.1.4). When I logged onto a VM on the same network I could perform a nslookup and the response was 10.1.1.4. In addition I used the SAS token for the blob container and uploaded some files using AzCopy and I used wireshark to monitor the traffic, which shows communication via the private network. 

 

I performed a few other tests:

I used AzCopy from laptop (not an Azure VM) and I found I could upload files to the blob container using the SAS token (So I connected to the blob container from a public network)

 

The next test I performed was to go to the 'firewall and virtual networks' for the storage account and enable 'selected networks' I repeated the test above and I was UNABLE to upload files. However if I whitelisted my public IP I could once again upload files via AzCopy. Both tests performed as I expected.

 

The final test involved uploading files from an Azure VM into the blob storage with AzCopy and the SAS token, but this time the Azure VM and the blob storage were on different subnets. The Azure VMs subnet was not added to the whitelist. I expected the AzCopy to fail for this test as the subnet was effectively not allowed to access the storage container?
Additionally I monitored the traffic via wireshark and it went over the private IP.

 

To summarize I am confused why the final test did not block access to the storage account as per the 'firewall and virtual network' configuration. Also in order to secure a storage blob with private link, is it wise to also use 'firewall and virtual network' to prevent access from a public network, as per the testing above?

1 Reply

  • Hi miksingh ,

     

    The reason your final test "passed" even though you expected it to "fail" is because 'firewall and virtual network' configuration is only used for configuring either the public endpoint or a service endpoint, but not the private endpoint. So this is a correct behavior.

     

    That is why you have two "tabs" in the "Networking" blade. Private Endpoints are seen as a superior option over Service Endpoints because you are targeting a specific Storage Account instance, rather than the Storage Service in each region.

     

    What most of my customers do, when they want to allow only private connectivity to storage accounts, is to:

    • enable Private Endpoint from a VNet/subnet that hosts workloads that need to access blobs or files
    • use 'Firewalls and Virtual Networks' configuration to block any other access (either using the public endpoint/IP or service endpoints). They don't add any VNets in this configuration!

    Please note that Private Endpoints are designed to work also from peered VNets or on-prem networks connected via VPN or Express Route (as long as you configure those networks to resolve your storage account FQDN using the private DNS zone, which is more complex topic for cross-premises configuration).