- Log in to the Azure portal at https://portal.azure.com ➢ enter Azure Synapse Analytics in the search box ➢ click Azure Synapse Analytics ➢ click the + Create button ➢ select the subscription ➢ select or create a new resource group ➢ provide a workspace name (I used csharpguitar‐vnet) ➢ select the region ➢ leave the From Subscription radio button enabled ➢ and then select the storage account and ADLS container that you provisioned in Exercise 18.15 (storage account example:csharpguitarvnet; ADLS container example:brainjammer‐vnet).
- Click the Next: Security > button ➢ enter a SQL password ➢ click the Next: Networking > button ➢ click the Review + Create button ➢ and then click Create.
On the Basics tab of the Azure Synapse Analytics workspace provision wizard, you may have noticed a message after selecting the ADLS account name. The message stated that the selected ADLS account must be used with a managed network and will be configured automatically. To view those configurations, navigate to the Networking blade of the storage account you selected in step 1 of Exercise 8.15 and created in Exercise 8.14. Notice that the Azure Synapse Analytics workspace you just provisioned is added to the resource instances list. The Allow Network Access check box on the Security tab enables you to add the Synapse Analytics workspace to the resource instances list, which affects the SQL pool access to the storage account. The managed VNet configuration is not visible on the storage account side, but it can ensure that Spark pools and pipelines can access the storage account. However, it also requires that a managed private endpoint be created. As previously mentioned, the addition of the Azure Synapse Analytics workspace into this networking configuration avoids the need to find the set of workspace IP addresses for the firewall address range. You may have also noticed that the workspace is not bound to the VNet you created in Exercise 8.14. It is instead contained within a managed VNet. You may recall the managed VNet concept applied around an Azure Synapse Analytics workspace from Figure 3.41. In general, the managed VNet that is provisioned with a workspace simplifies the setup and configuration of the workspace networking component.
The other configuration performed on the storage account when the workspace is bound to the storage account protected by a VNet is a managed private endpoint. A managed service endpoint is created automatically when you choose the managed VNet configuration and needs to be approved on the storage account side. On the Networking blade, select the Private Endpoint Connections tab, select the Private Endpoint check box, and then click the Approve button. Figure 8.53 shows the configuration.
FIGURE 8.53 Azure storage account private endpoint configuration
This changes the flow between the workspace and the ADLS container, as opposed to that shown in Figure 3.41, in that there is now an additional private endpoint. The added private endpoint is the new entry point to the storage account containing your ADLS container. You will find the same private endpoint in Synapse Studio on the Managed Private Endpoints blade, accessible via the Manage Hub. Private endpoints are a way to provide a public endpoint with a private IP address. When a private endpoint is created, it uses a private IP address from the VNet, adding an additional layer of security. Additional security is realized because when a private endpoint is added, you are effectively adding the resource into the VNet—in this case, the managed VNet. And, by default, only resources within that VNet have access to the resources within it.
Another networking security feature is a network security group (NSG). An NSG is provisioned by default when you create a VNet; you will find it in the same resource group that the VNet is in. As shown in Figure 8.54, NSGs can be applied to both inbound and outbound network traffic. You can also see that there is a rule named AllowVnetInBound that allows all port numbers and all protocols within the virtual network, which includes all subnets.
FIGURE 8.54 Network security group rules
To add a security rule, click the + Add button. The resulting pop‐out window provides the interface to configure all the attributes of a security rule. You can create a rule that targets a specific protocol, like HTTP, SSH, SMTP, and FTP, and identifies which ports are allowed or denied usage for inbound connectivity, for example, port 80 or port 25. These rules are helpful in locking down the network traffic flowing into and out of the VNet to only what you know should be happening. On the Outbound Security Rules blade, you will see a rule named AllowInternetOutBound with a destination value of Internet. If you want to deny all traffic to the Internet, you can change that so the action value is Deny. This is often done when a networking administrator wants to implement something called forced tunnelling.
The last networking security component to discuss is the firewall. A standalone Azure Firewall product provides access to lower level OSI layers than the ones you have seen previously. If, and only if, your security design requires security at those lower levels should you use Azure Firewall. Otherwise, the built‐in firewall’s access‐restricting capabilities, as shown in Figure 8.52, will be enough. In this context, a firewall is a virtual device that allows or prohibits access to resources based on the IP address of the device requesting the resource. Using all the networking security concepts, such as private endpoints, firewalls, NSGs, and VNets, you can have a very secure networking security layer to protect your data.
