VNET Service Endpoints

A long awaited functionality of multiple of our PaaS services was to link them to a virtual network. At Ignite, Microsoft announced Service Endpoints. This finally met this popular request, at least for storage accounts and SQL DBs.
Endpoints allow you to secure your critical Azure PaaS resources to only your virtual networks. Traffic from your VNET to the Azure service always remains on the Microsoft Azure backbone network. Nobody from outside your VNET will be able to access your PaaS services if you enable service endpoints.
Let’s have a look at what this looks like for storage accounts:

Setting up VNET service endpoints

First: let’s create a new storage account, and upload some files to it via our storage explorer. For those of you that don’t know storage explorer, it is an easy BLOB storage management interface. I use it often to upload/download files to blob, as it has an easy-to-use GUI.
If you pay close attention to the screenshots above, you’ll notice you can enable Service Endpoints when creating the storage account. I purposely didn’t do it while creating the storage account, as I first want to upload some files to it.


With some files in the storage account, let’s see if we can see those files. Building on our work from last week, we’ll use the FUSE driver on Linux to work with the files on blob. Some quick steps to mount the blob container:
 

1. Change our connection.cfg to include our storage account. Important to note here: you still need the storage account key, even with service endpoints
2. Mount to a new directory. I created a new directory files in my home drive, and mounted the blob container there.

Enabling the service endpoints isn’t complicated. You enable (in the portal) from within the storage account blade (see below). You can link multiple VNETs and multiple subnets.

Testing it out

Immediately afterwards, I couldn’t access my storage account anymore from the storage explorer, as expected. Writing a small txt file from within my VM was possible though. As expected!

You do have the possibility to add IP addresses to this firewall now. Let’s allow connectivity from my client machine and see what happens (I honestly don’t know what will happen here).
What I noticed:

• With an open firewall rule for my machine I was:
  • Able to connect to the storage account from storage explorer on my machine.
  • Able to download blobs from listing the storage account in the Azure portal.
  • I was able to see my txt file that I created using the VM earlier.
• With a closed firewall (I deleted my IP again) I was:
  • Not able to connect to the storage account from storage explorer on my machine.
  • NOT able to download blobs from listing the storage account in the Azure portal

So everything works pretty well, even the Azure portal takes your IP address into account when listing blobs with service endpoints.

Conclusion

• Service endpoints are very easy to set up.
• Service endpoints and the storage account key (or SAS tokens) offer different levels of protection. Service endpoints offer network level security, where the storage account key or a SAS token offers protections on the access to the storage account. You need both (to pass through the service endpoints firewall and to have the account key or SAS token) to have access to your storage account.
• All toolings work well with the service endpoints, even the Azure portal. If you don’t have access with service endpoints, the portal will not show you which data is in your storage account.