- Log in to the Azure portal at https://portal.azure.com ➢ click the menu button in the upper left of the browser ➢ select + Create a Resource ➢ click Storage ➢ click Storage Account (if not found, search for storage account) ➢ select it ➢ and then click Create.
- Select the Subscription and Resource group into which you want to create the storage account ➢ enter a storage account name (I used csharpguitarvnet) ➢ enter a location (which should be the same as the resource group location, but it is not required) ➢ choose Standard Performance ➢ and then select Locally Redundant Storage (LRS) from the Replication drop‐down.
- Click the Next: Advanced > button ➢ check the Enable Hierarchical Namespace check box in the Data Lake Storage Gen2 section ➢ check the Enable Network File System v3 check box in the Blob Storage section ➢ and then click the Next: Networking > button.
- Select the Enable Public Access from Selected Virtual Networks and IP Addresses radio button ➢ select the Virtual Network Subscription ➢ select the Create Virtual Network link below the Virtual Network drop‐down ➢ enter a name (I used brainjammer‐vnet) ➢ select the default address ranges for both the VNet and the subnet, as shown in Figure 8.51 ➢ and then click OK.
FIGURE 8.51 Adding an Azure storage account with an ADLS container to a VNet
- Click the Review button (feel free to navigate through the other tabs, but leave the defaults), and then click Create.
- Once the provision is complete, navigate to the Overview blade of the storage account ➢ select the Data Lake Storage link on the Overview blade or Containers from the navigation menu ➢ click + Container ➢ enter a name (I used brainjammer‐vnet) ➢ select Private (No Anonymous Access) from the Public Access Level drop‐down list box ➢ and then click Create.
- Select the Networking navigation link. The configuration should resemble Figure 8.52.
FIGURE 8.52 The Azure storage account VNet configuration
- Check the Add Your Client IP Address box in the Firewall section, and then click Save.
Provisioning Azure resources should not be anything new or challenging at this point. What was new in Exercise 8.14 was the provisioning of the VNet. When you selected the Enabled from Selected Virtual Networks and IP Addresses radio button, you were provided the option to create a new virtual network. As the radio button name implies, once configured, only networks and IP addresses that have been granted access will be able to connect to this Azure storage account. While making the network configuration, you may have noticed a new term, CIDR notation. Classless Inter‐Domain Routing (CIDR) is the method used to allocate IP addresses to a network’s address space. The address space allocated to the VNet is from 10.1.0.0 to 10.1.255.254, which means you can have up to approximately 65,531 devices connected to the VNet. The CIDR range is defined by the number that comes after the / (in this case, 16). Notice in the subnet configuration portion that the range is defined by /24, which is a smaller number of IP addresses (251, for example). The smaller the number after the slash (/), the larger the number of IP addresses allocated to the network. The numbers range from /0 through /32. It is also important to call out that when you are configuring a subnet, the CIDR range must reside within the VNet’s address space.
Figure 8.52 includes two additional sections that should be discussed: Firewall and Resource Instances. Had you not added your client IP address to the list of allowed IP addresses, you would not be able to access any content within the containers. The same goes for any client or server from now on, in that, if the IP address is not in the allowed address range list or is not part of the VNet, then access will be denied, regardless of any RBAC or ACL permission. That makes sense because of where the network security layer exists. (It is the first layer in Figure 8.1.) That it fails so early means there is no chance to observe any Access Management or Information Protection permissions.
Another approach for granting access to the Azure storage account is by using resource instances. In Exercise 3.14 you added an IP range of 0.0.0.0 through 255.255.255.255, which effectively allowed connectivity from everything through the network layer. This was done because it is inherently difficult to find IP addresses internal to Azure. For example, if you want to allow access from your Azure Synapse Analytics workspace to this Azure storage account, which IP address would you use? Although these lists do exist, a better approach might be to select Microsoft.Synapse/workspaces from the Resource Type drop‐down list box and then select either a specific workspace or one of the other options—for example, all workspaces in the Azure AD tenant, in the current subscription, or in the current resource group. Doing so would avoid the requirement to find IP address ranges for all the datacenters in which your resources exist and the management required to apply and maintain them.
Now that you know more about VNets, perform Exercise 8.15, where you will provision another Azure Synapse Analytics workspace, bind it to the same VNet, and test connectivity.
