Disabling Public Network Access in Synapse

 

Author: Ryan Adams is a Program Manager in Azure Synapse Customer Success Engineering (CSE) team. 

 

If you disable public access to your Azure Synapse Workspace you will get the following error message when attempting to open Synapse Studio. 

 

“Failed to load one or more resources due to forbidden issue, error code 403.” 

 

 

If you click on details, you’ll see the following: 

 

Most users end up with this error page and don’t know that disabling Public Network Access was the cause and that makes troubleshooting much more difficult.  Receiving an error after disabling Public Network Access is by design and expected.

 

The first thing we see is the error code being 403.  That’s an HTTP/HTTPS Forbidden error code and not a code from the Synapse service. This indicates the issue is accessing the service via HTTP/HTTPS and most likely network related. 

 

In this state, you might also see your SQL Pools show to be “Unavailable” in the Manage Hub. If you click OK on the error message, select the Manage Hub on the left, and SQL Pools under the Analytics Pools section you can view the status of your SQL Pools. 

 

 

 

Disable Public Network Access 

You can easily verify if Public Network Access has been enabled or not in the Azure portal.  Simply navigate to your Synapse Workspace resource and go to the networking section.  The very first option has a radio button indicating if Public Network Access is enabled or disabled. If it is set to disabled, you’ll see an information icon informing you that private endpoints will be required. 

 

 

It's important to note that enabling Public Network Access is not opening your workspace up to the entire internet.  If you enable it, the service puts a firewall in front of it.  However, you do need to be aware that the default allowAll range (enabled during workspace creation) is indeed the entire internet.  You simply need to change the default rule to only allow your trusted networks, or delete it and create new allow rules.  In addition, we use cold potato routing so if all your allowed networks are in Azure then the traffic never leaves the Azure backbone. 

 

 

  

Create private endpoints 

If you have chosen to disable Public Network Access and are receiving the above error message when opening the portal, then you will need to create Private Endpoints to access your workspace.  This can sometimes be confusing as there are two places where Private Endpoints can be created so we need to understand the difference.  The first location is inside the workspace under the Manage Hub.  Depending on the resources you have created, you will likely see three entries already there.  These are automatically created for you so the workspace can access Storage, Dedicated Pools, and Serverless Pools. 

 

 

 

 

The second location is in the Azure Portal on the Synapse Workspace resource.  By default, this will be empty and is where you need to create private endpoints to resolve the issue in our original error message. 

 

 

 

 

There are three private endpoints you will want to create unless you do not plan to use a Dedicated Pool or Serverless Pool.  Each private endpoint will need to be connected to a target VNET, which should be the network location from where you plan to access your workspace. 

 

 

 

On the Virtual Network tab, you select the VNET from where you plan to manage your workspace and on the DNS tab, you need to select “Yes” to integrate with a Private DNS Zone. If you are already running your own DNS implementation, then can alternately create "A" records for the Private Endpoints there.

 

 

 

Once the “Dev” target sub-resource is created the error on the workspace portal will be resolved.  Once the SqlOnDemand target sub-resource is created, the Serverless Pool will turn from “Unavailable” to “Online”. Once the Sql target sub-resource is created, the Dedicated Pool will turn from “Unavailable” to “Online”. 

 

What is inside and outside of a managed workspace VNET 

Now that you know there are two places to create private endpoints depending on whether it is traffic coming into or going out of the workspace, let’s take a closer look at what is inside and outside of the Synapse Managed Workspace VNET. 

 

The short answer is Spark pools are inside the workspace VNET while serverless and dedicated pools are outside the workspace VNET.  This is why you get private endpoints created in the workspace automatically for serverless and dedicated pools.  Review the diagram below to get a good visualization of what this looks like.  I also highly recommend reading a post by fellow colleague Benjamin Leroux on Understanding Azure Synapse Private Endpoints. 

 

 

Accessing the private endpoint through peered VNETs 

A common practice in cloud networking is to use a hub and spoke architecture.  In this case, you will want to create your private endpoints in the hub network.  Any other VNET or spoke that is peered to the hub will be able to access the workspace.  Here is an example of what that might look like: 

 

 

 

When using private endpoints, you will need a private DNS zone or your own DNS so applications can resolve the endpoint names.  There is an extra step needed to link your spoke VNETs to the private DNS zone in your hub network.  Go to the private DNS zone in your hub network and select “Virtual Network Links” (You will see a link already created for the hub VNET) and then click “Add”.  Simply name your link and select the spoke network from the drop-down menu. 

 

 

Creating multiple private endpoints 

If you are not using a hub and spoke network architecture or prefer to not rely on VNET peering, there is one last choice.  You can create private endpoints in each VNET where you plan to manage your workspace.  Remember that you most likely will need to create three private endpoints (one each for the portal or Dev, Dedicated Pools, and Serverless Pools) in each VNET.  If you have 10 VNETs that will need to access the workspace, then you must create 30 Private Endpoints. 

 

For this scenario, you can simply follow the instructions provided above for creating the private endpoints.  You must repeat it for every spoke network that you want to have access to your Synapse workspace.  The other difference will be DNS.  Since there is no peering involved, services in spoke networks cannot access the Private DNS Zone in the hub network.  You will need to create a Private DNS zone in each network or utilize a centralized DNS. 

 

Here is what that might look like when utilizing private DNS zones: 

 

 

Demo

Watch this video to learn how to disable public network access.

 

Conclusion 

You have several options for securing network access to your Azure Synapse Workspaces. 

• Enable Public Network Access and use the built-in firewall to only allow trusted networks.  
• Use private endpoints and manage the workspace from a single VNET. 
• Use private endpoints and access the workspace through peered VNETs. 
• Use private endpoints in every VNET that needs access to the workspace. 

 

Our team publishes blog(s) regularly and you can find all these blogs here: https://aka.ms/synapsecseblog. For deeper level understanding of Synapse implementation best practices, please refer our Success by Design (SBD) site: https://aka.ms/Synapse-Success-By-Design  

 

Continue to website...