Configure inbound Private Link for workspaces

This page provides instructions to configure inbound private connectivity between users and their Azure Databricks workspaces.

Why choose an inbound connection?

Whether you use serverless or classic compute, users must connect to Azure Databricks. Organizations choose to connect to Azure Databricks for several reasons, including the following:

  • Enhanced security: By restricting all access to private endpoints and disabling public access, you minimize the attack surface and verify all user interactions with Azure Databricks occur over a secure, private network.
  • Compliance requirements: Many organizations have strict compliance mandates that require all data and management plane traffic to remain in their private network boundaries, even for SaaS services like Azure Databricks.
  • Simplified network architecture (for specific use cases): If you are only using serverless compute, or your primary interaction with Azure Databricks is through the web UI or REST APIs, and you have no immediate need for private connectivity to data sources from Azure Databricks (which requires a classic compute plane Private Link connection), an inbound-only setup simplifies the overall network design.
  • Data exfiltration prevention: By preventing public access and forcing all traffic through private endpoints, you reduce the risk of data exfiltration, ensuring traffic can only be accessed from authenticated network environments.

Connectivity model

You can configure private connectivity in one of two ways:

  • No public access: This configuration disables all public access to the workspace. All user traffic must originate from a VNet connected through a private endpoint. This model is required for full traffic privatization. For full traffic privatization you also need a classic compute plane Private Link connection. See Private Link concepts.
  • Hybrid access: Private Link is active, but public access remains enabled with context-based ingress controls and IP access lists. Context-based ingress controls let you restrict access based on identity, request type, and network source. This allow you to safely permit access from trusted public sources (for example, static corporate IPs), while still using Private Link for private connectivity.

This guide explains how to implement the hybrid access model. We achieve this using a standard hub-and-spoke network topology.

Architecture overview

This model uses the transit VNet:

  • Transit VNet: This is your central virtual network containing all the private endpoints needed for client access to workspaces and browser authentication. Your browser authentication workspace also connects to this VNet.

Azure Private Link network architecture.

Before you begin

Review the following prerequisites and recommendations:

Requirements

Networking configuration

  • A transit VNet configured for the following:
    • It acts as the primary transit point for all user/client traffic connecting to your Azure network.
    • It provides centralized connectivity for on-premises or other external networks.
    • It manages shared services and contains the primary route for outbound internet traffic (egress).
  • Your private DNS zones are managed by Azure DNS.

Best practices

Azure Databricks recommends the following for a resilient and manageable setup:

  • Architecture: Your network must follow the Microsoft-recommended hub-spoke architecture. See Hub-spoke network topology in Azure.
  • Isolated authentication workspace: For improved resilience, create a separate browser authentication workspace inside your transit VNet. This dedicated workspace should host the browser-authentication private endpoint, preventing a single point of failure if other workspaces are deleted. See Create a browser_authentication workspace.

Configure private connectivity for an existing workspace

Before you begin, you must stop all compute resources like clusters, pools, or classic SQL warehouses. No workspace compute resources can be running, or the upgrade attempt fails. Azure Databricks recommends planning the timing of the upgrade for downtime.

  1. On the Workspaces page, select Compute.
  2. Select each active compute cluster and in the top-right, click Terminate.

Verify VNet-injected workspace with public access enabled

  1. Go to your Azure Databricks workspace in the Azure portal.
  2. In the workspace overview section, verify your Azure Databricks workspace uses your own virtual network:
    1. Under Settings, select the Networking tab. Confirm the following settings:
      1. Secure cluster connectivity (No Public IP) is enabled.
      2. Allow Public Network Access is Enabled.

Create databricks_ui_api private endpoint

  1. From your workspace's Networking tab, select Private endpoint connections.
  2. Click Plus icon. Private endpoint.
  3. Select the resource group for the endpoint, provide a name like my-workspace-fe-pe. Verify the region matches your workspace.
  4. Click Next: Resource.
  5. Set Target sub-resource to databricks_ui_api.
  6. Click Next: Virtual Network.
  7. Select your transit VNet. Your transit VNet is a separate, pre-existing VNet in your network architecture that manages and secures egress traffic, often containing a central firewall.
  8. Select the subnet that hosts the private endpoints.
  9. Click Next and verify Integrate with private DNS zone is set to Yes. It should automatically select the privatelink.azuredatabricks.net zone.

Note

Link the private DNS zone to your transit VNet and, for better organization, place it in a separate resource group with your other private DNS zones.

Create a browser_authentication workspace

Create a private endpoint for browser authentication to support SSO over your private network path. Azure Databricks recommends hosting this endpoint on a dedicated private web auth workspace.

Create a resource group

  1. In the Azure portal, navigate to and select Resource groups.
  2. Click + Create.
  3. Provide a Name for the resource group, such as web-auth-rg-eastus.
  4. For Region, select the same Azure region where your production Databricks workspaces are deployed.
  5. Click Review + create, then Create.

Create a VNet

  1. In the Azure portal, search for and select Virtual networks.
  2. Click + Create.
  3. On the Basics tab, select the Resource group you just created and give the VNet a descriptive Name, like web-auth-vnet-eastus.
  4. Verify the Region matches your resource group.
  5. On the IP Addresses tab, define an IP address space for the VNet, for example, 10.20.0.0/16. You are also prompted to create an initial subnet.
  6. Select Review + create, then Create.

Create and secure the private web auth workspace

  1. In the Azure portal, search for and select Azure Databricks. Click + Create.
  2. On the Basics tab, configure the following:
    1. Select the Resource group you just created.
    2. Give the workspace a descriptive name, like WEB_AUTH_DO_NOT_DELETE_<region>.
    3. Select the same region as your resource group and VNet.
  3. Click Next:Networking and configure the following:
    1. Deploy Azure Databricks workspace with Secure Cluster Connectivity (No Public IP): Select Yes.
    2. Deploy Azure Databricks workspace in your own Virtual Network (VNet): Select Yes.
    3. Virtual Network: Select the VNet you just created. You are prompted to define subnet ranges.
    4. Public Network Access: Select Disabled.
    5. Required NSG Rules: Select NoAzureDatabricksRules.
  4. Click Review + create, then Create.

After you create the workspace, protect it from accidental deletion.

  1. In the Azure portal, navigate to the workspace you just created.
  2. Go to Settings and select Locks.
  3. Click + Add.
  4. Set the Lock type to Delete and provide a descriptive Lock name.
  5. Click OK.

Note

  • Do not run any Databricks workloads, such as clusters, jobs, in this workspace.
  • Do not add any private endpoints other than browser_authentication. Specifically, do not create a databricks_ui_api endpoint for this workspace.

Create the browser_authentication private endpoint

After creating the workspace, you must create the browser_authentication private endpoint to connect it to your transit VNet.

  1. From the web auth workspace's Networking tab, select Private endpoint connections.
  2. Click Plus icon. Private endpoint.
  3. Select the resource group for the endpoint, provide a name like web-auth-browser-auth-pe. Verify the region matches your workspace.
  4. Click Next: Resource.
  5. Set Target sub-resource to browser_authentication.
  6. Click Next: Virtual Network.
  7. Select your transit VNet (the same VNet used for the databricks_ui_api private endpoint).
  8. Select the subnet that hosts the private endpoints.
  9. Click Next and verify Integrate with private DNS zone is set to Yes. It should automatically select the privatelink.azuredatabricks.net zone.
  10. Complete the endpoint creation.

Configure and verify DNS

After you deploy the private endpoints, you must verify that DNS correctly resolves Azure Databricks URLs to their new private IP addresses.

  1. Verify private DNS zone records:
    1. In the Azure portal, search for and navigate to the Private DNS zone named privatelink.azuredatabricks.net.
    2. Verify the following A records exist and point to the private IP addresses of your endpoints:
      1. Workspace UI/API record:
        • Name: Your unique workspace ID, like adb-xxxxxxxxxxxxxxxx.x
        • Value: The private IP address of your databricks_ui_api private endpoint.
      2. Browser authentication record:
        • Name: Choose a descriptive name like pl-auth.<your_region>.
        • Value: The private IP address of your browser_authentication private endpoint.

Verify private network access

Confirm that you can access the workspace through your private network connection.

From a connected network

If your on-premises network already connects to your Azure VNet by VPN or ExpressRoute, the test is simple:

  • From your computer, open a web browser and go directly to your Azure Databricks workspace URL to log in. A successful login confirms that your private connection works.

Using a test VM

If you cannot access the workspace VNet from your current location, create a temporary virtual machine (a "jump box") to test from:

  1. Create a VM: In the Azure portal, create a Windows virtual machine. Place it in a subnet using the same transit VNet where you configured your inbound private endpoint.
  2. Connect to the VM: Use a Remote Desktop client to connect to your new VM.
  3. Test from the VM: After you connect to the VM, open a web browser, go to the Azure portal, and find your Azure Databricks workspace.
  4. Launch Workspace: Click Launch Workspace. A successful login confirms that access from within your private VNet works correctly.

Verify DNS with nslookup

  1. Connect to a virtual machine inside your configured VNet or to your on-premises network via VPN or Azure ExpressRoute. Your machine must be able to use Azure's private DNS.
  2. Open a command prompt or terminal and use nslookup to verify DNS resolution.
# Verify the workspace URL resolves to a private IP
nslookup adb-xxxxxxxxxxxxxxxx.x.azuredatabricks.net

# Expected output:
# Server:  <your-dns-server>
# Address: <your-dns-server-ip>
#
# Name:    adb-xxxxxxxxxxxxxxxx.x.privatelink.azuredatabricks.net
# Address: 10.10.1.4  <-- This should be the private IP of your 'databricks_ui_api' endpoint
# Aliases: adb-xxxxxxxxxxxxxxxx.x.azuredatabricks.net

Create general_access private endpoint

Important

Private access to workspaces using the general access endpoint is in Beta.

Create a private endpoint for custom URL access to your workspace. This step is only needed if you want to access your workspace with your custom URL, for example, <my-custom-account-name>.azuredatabricks.net.

Note

If you already use your custom URL for inbound Private Link to account-level resources (see Configure inbound Private Link for account-level resources), you can reuse the existing general_access private endpoint to access account-level resources. In this case, you only need to complete Allowlist your private endpoint to workspaces with context-based ingress.

Prepare VNet and subnet

Prepare a VNet and subnet to host the private endpoint. You can create a new VNet or reuse an existing one, such as your workspace VNet.

  1. To create a new VNet, see Create an Azure Virtual Network.
  2. To add a subnet, see Add, change, or delete a virtual network subnet.
  3. Verify that the Private endpoint network policy is Disabled in your subnet. This is the default setting. See Manage network policies for private endpoints for details.

If you reuse an existing workspace VNet, you must use or create a different subnet from the one used by the workspace. If the VNet hosting the private endpoint differs from the VNet sending traffic, configure VNet peering or connectivity. See Verify VNet connectivity.

Deploy a private endpoint

  1. In the Azure portal, search for Private endpoints in Microsoft Marketplace and select Create.
  2. Enter a name and network interface name, and set the region to match your workspace VNet region.
  3. Click Next: Resource.
  4. Select Connect to an Azure resource by resource ID or alias.
  5. In the Resource ID or alias field, enter the Private Link Service resource ID for general_access services for your region. See Private Link Service Resource IDs for performance-intensive services and general access for the list of resource IDs.
  6. In the Target sub-resource field, enter general_access.
  7. Click Next: Virtual Network.
  8. Select the virtual network and subnet that you prepared in the Prepare VNet and subnet section.
  9. Click Next: DNS.
  10. Leave Integrate with private DNS zone set to No. You configure DNS manually later.
  11. Click Next: Tags.
  12. Click Next: Review + create.
  13. Review the configuration and click Create to deploy the private endpoint.
  14. After the deployment completes, record these values:
    • Private endpoint name: The name of your private endpoint.
    • Resource GUID: Go to the private endpoint resource, click JSON view, and find the value in properties.resourceGuid. This is required when you register your private endpoint.
    • Private IP address: In JSON view, find the IP address in properties.customDnsConfigs[0].ipAddresses[0]. This is required when you configure DNS.

Note

After deployment, the private endpoint connection state shows as Pending. This is expected. The endpoint remains in Pending state until you register your private endpoint.

Register your private endpoint

After you create your private endpoint in the Azure portal, register it with Azure Databricks.

  1. Go to the Azure Databricks account console.
  2. In the sidebar, click Security > Networking > Endpoints > Register endpoint.

Allowlist your private endpoint to workspaces with context-based ingress

Important

Private access to workspaces using context-based ingress is in Beta.

  1. In the account console, click Security in the sidebar.
  2. Click Context-based ingress & egress control in the sidebar.
  3. Under Workspace level policies, click New workspace policy.
  4. Under Ingress > Private Network Access, define your private access policy.
    1. By default, all registered endpoints are allowed: Allow access from all private endpoints. If this is acceptable, proceed to the next step. This default includes only the first 200 registered private endpoints; if your policy requires more, contact your account team for an increase.
    2. If you want to allowlist specific registered endpoints while denying all other endpoints, uncheck Allow access from all private endpoints and add an allow rule.
      1. Select the identities and workspace destinations you want to allow access to (by default, all identities and destinations are allowed).
      2. For Source type, select Selected private endpoints, and select the general access private endpoint(s) you registered. The region of this private endpoint does not have to match the region of your workspace. A general access endpoint in any region can serve workspaces in any region.
      3. Click Confirm.
      4. You can also add Deny rules in your policy, which define exceptions to your allow rules.
  5. When you are done configuring your private access policy, you can also configure your public access policy in Ingress > Public Network Access. You can disable all public IP access by unchecking Allow access from all public IPs. Azure Databricks recommends keeping public access enabled while testing your DNS configuration, then disabling it after DNS is finalized to enforce exclusive private connectivity.
  6. Test your ingress policy in Dry run mode first, before switching it to Enforced. Dry run mode access denials are logged in the system.access.inbound_network system table but do not block access.
  7. Make sure your Egress policy is correct.
  8. Attach your network policy to your workspace(s). Workspaces without this general access endpoint allowlisted are not accessible through your custom URL.
  9. Save your network policy. Context-based ingress policy updates take under 10 minutes to take effect.

Configure DNS for the general access endpoint

After your private endpoint is registered and allowlisted, configure DNS so workspace traffic routes through the private endpoint using your custom domain, <my-custom-account-name>.azuredatabricks.net.

  1. Create an Azure private DNS zone named <my-custom-account-name>.azuredatabricks.net. If you already configured a general_access private endpoint for inbound Private Link to your account-level resources (see Configure inbound Private Link for account-level resources), reuse the existing <my-custom-account-name>.azuredatabricks.net zone. For new zones, see Create an Azure private DNS zone using the Azure portal.
  2. Link the private DNS zone to the VNet hosting your private endpoint. See Link the virtual network.

Create DNS A record

  1. Go to your new private DNS zone.
  2. Select the Recordsets tab under DNS Management.
  3. Click Add to add a record set.
  4. Configure the A record:
    • Name: @
    • Type: A
    • IP address: The private IP address from your private endpoint.
  5. Click OK to save the record.

Verify DNS resolution

From a machine in your VNet or from a workspace job attached to your private DNS zone, confirm that DNS queries resolve to the private endpoint IP:

nslookup <my-custom-account-name>.azuredatabricks.net

Or use dig:

dig <my-custom-account-name>.azuredatabricks.net

Both commands return the private IP address of your private endpoint.

Verify VNet connectivity

If the VNet generating traffic differs from the VNet hosting the private endpoint, configure VNet peering or connectivity between them. See Azure Private Endpoint DNS Integration Scenarios for detailed guidance.

Custom DNS configuration

When using a private inbound endpoint with your own custom DNS, you must verify that both the workspace URL and the SSO (single sign-on) authentication URLs resolve correctly to the private endpoint's IP address.

The most reliable method is to configure your DNS server to forward queries for all Databricks domains to Azure's internal DNS.

  1. Set up conditional forwarding for the following domains to your Azure DNS server:
    • *.azuredatabricks.net
    • *.privatelink.azuredatabricks.net
    • *.databricksapps.com
    • Your custom URL: <my-custom-account-name>.azuredatabricks.net
  2. Verify that your VNet links to the Azure Private DNS Zone.

This allows Azure to automatically resolve all necessary hostnames, including SSO and workspace URLs, to your private endpoint's IP address.

Alternative: Manual A Records

If conditional forwarding is not an option, you must manually create DNS A records.

  1. Workspace URL: Create an A record mapping your per-workspace URL, such as adb-1111111111111.15.azuredatabricks.net, to the private endpoint IP address.
  2. SSO Authentication URL: Create an A record mapping the regional SSO URL, such as westus.pl-auth.azuredatabricks.net, to the private endpoint IP address.
  3. Your custom URL: Create an A record mapping your custom URL, such as <my-custom-account-name>.azuredatabricks.net, to the private endpoint IP address.

Some Azure regions use multiple control plane instances for SSO. You might need to create several A records for authentication. Contact your Azure Databricks account team for the complete list of domains for your region.

Additional resources