cancel
Showing results for 
Search instead for 
Did you mean: 
Administration & Architecture
Explore discussions on Databricks administration, deployment strategies, and architectural best practices. Connect with administrators and architects to optimize your Databricks environment for performance, scalability, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to properly restrict public network access on Azure Databricks Managed Root Storage?

mariof
New Contributor

Hi,

Our main goal right now is to disable public network access on the Managed Root Storage Account (the one created automatically in the managed resource group dbresources... which contains containers like ephemeral, root, meta, and unity-catalog-storage).

When reviewing the Networking tab of this specific storage account in the Azure Portal, it is currently configured as "Enabled from all networks".

I created 2 private endpoints (dfs, blob) in  Managed Root Storage Account .Could this be the final solution to restrict public access, or what are the next steps I need to follow?

We currently have Serverless Compute and Clasic Compute (No serverless).

Just to clarify, we are not talking about external business data storage, but strictly about the workspace system root storage (dbstorageiq..)

 

 

 

1 REPLY 1

szymon_dybczak
Esteemed Contributor III

Hi  @mariof  ,

It possible and all details are well described in following article:

Enable firewall support for your workspace storage account - Azure Databricks | Microsoft Learn

Before enabling the firewall, the docs are explicit about several hard requirements. You need to verify all of these:

- VNet injection must be enabled on your workspace for connections from the classic compute plane.

Secure Cluster Connectivity (No Public IP / NPIP) must be enabled for connections from the classic compute plane.

- The workspace must be on the Premium plan

- You must have a separate dedicated subnet for the private endpoints

- You must create an Azure Databricks Access Connector (with system-assigned or user-assigned managed identity) and save its resource ID before enabling the firewall. You cannot use the access connector in the managed resource group -  it must be in a separate resource group. 

 

So, basically you need to perform following steps:

1. Verify your private endpoints are in the correct subnet.

2. Confirm endpoint approval

3. Create an Access Connector (if not already done)

4. Enable the firewall via Azure CLI or PowerShell

This is the key step that actually flips the storage account from "Enabled from all networks" to private. Use Azure CLI:

 
bash
az databricks workspace update \
   --resource-group "<your-resource-group>" \
   --name "<your-workspace-name>" \
   --subscription "<subscription-id>" \
   --default-storage-firewall "Enabled" \
   --access-connector "{\"id\":\"/subscriptions/<sub-id>/resourceGroups/<rg>/providers/Microsoft.Databricks/accessConnectors/<connector-name>\", \"identity-type\":\"SystemAssigned\"}"

Serverless Compute Consideration

Since you have both Serverless and Classic compute, there's an important nuance:

When you enable firewall support, Azure Databricks automatically onboards the workspace storage account to a network security perimeter that allows the AzureDatabricksServerless service tag, enabling serverless compute to connect via service endpoints. For private endpoint connectivity from serverless, you need an additional private endpoint rule in your Network Connectivity Configuration (NCC). microsoft

Azure Databricks is currently onboarding all existing workspace storage accounts with enabled firewalls to a network security perimeter allowing the AzureDatabricksServerless service tag, with onboarding expected to complete by end of 2026

 

If my answer was helpful, please consider marking it as accepted solution.