Del via


Configure networking for Databricks Apps

Databricks Apps supports fine-grained network control to help you secure and manage how your app communicates with the internet and internal resources. You can configure both ingress (incoming) and egress (outgoing) traffic rules using a combination of IP access lists, front-end private connectivity, and network policies.

Network architecture

Azure Databricks deploys apps on the serverless compute plane, where they receive traffic directly. This is similar to other route-optimized services like Model Serving and Vector Search.

The connection process operates as follows:

  1. Initial user requests to an Azure Databricks app initiate OAuth authentication with the control plane to validate the session and authorize access to the app.
  2. Upon successful authentication, all subsequent requests are routed directly to the serverless compute plane without traversing the control plane.

Network security policies configured for the serverless compute plane apply to Databricks Apps traffic. This includes IP access lists and front-end private connectivity configurations.

Ingress controls

Use the following features to limit access to your Azure Databricks workspace and apps from the public internet.

  • IP access lists: Restrict workspace and app access to known and trusted IP ranges by enabling IP access lists at the workspace level. Only traffic from the configured IP ranges is allowed. For details, see Configure IP access lists for workspaces.
  • Front-end private connectivity: Route ingress traffic through an Azure Private Link connection to securely access apps over your VNet.

    You must configure conditional DNS forwarding for the databricksapps.com domain to ensure proper name resolution through your private connection. Otherwise, DNS queries for your app's domain might resolve to public IP addresses instead of the private endpoint. For setup instructions, see Configure Inbound Private Link.

    Legacy regional URLs aren't supported with Databricks Apps because they don't support OAuth, which is required for app authentication. For details, see Legacy regional URL.

Egress controls

To control outbound traffic from your app, create a network connectivity configuration (NCC) and apply network policies to the workspace hosting the app.

Network connectivity configurations

Use a network connectivity configuration to securely connect your app to Azure services. NCCs provide stable subnet IDs that you can add to a storage account firewall to explicitly allow access from your app and other serverless compute.

To further restrict egress traffic to private destinations, configure serverless private endpoints for Azure resources or route traffic through an Azure load balancer in your VNet.

Network policies

Use network policies to enforce egress restrictions on Databricks apps and other serverless workloads. This is useful when you need to meet organizational or compliance requirements for controlling outbound connectivity.

Note

Network policies are only available on the Premium tier.

Apply a network policy if your app:

  • Must limit access to a specific set of approved external domains
  • Needs to prevent accidental data exfiltration
  • Must comply with security or compliance standards that restrict outbound internet traffic

Required egress domains for app deployment

When you use restricted egress network policies, you must allowlist specific domains for app builds or runtime to succeed. Without these domains, app deployments fail because the build process can't download dependencies or communicate with required services.

The following domains are required for all Databricks apps deployments:

Domain Purpose
*.databricksapps.com App serving and user connectivity
pypi.org, files.pythonhosted.org Python package downloads during app builds (required if your app uses requirements.txt)
registry.npmjs.org Node.js package downloads during app builds (required if your app uses package.json)

:::

Additionally, Azure deployments might require these domains:

Domain Purpose
*.blob.core.windows.net Azure Blob Storage endpoints used by apps that connect to Azure storage
*.dfs.core.windows.net Azure Data Lake Storage endpoints used by apps that connect to ADLS

:::

:::

Your app might require additional domains depending on your specific dependencies or the external APIs it calls. For example, if your app calls a third-party REST API, add that API's domain to the allowlist.

Important

In Private Link environments with restricted egress, missing domain allowlist entries commonly cause app deployment failures. If your app fails to deploy, check the system.access.outbound_network system table for denied connection attempts to identify which domains to add. See Check denial logs.

Best practices for configuring network policies

Follow these guidelines to avoid unintended disruptions and ensure that your apps can access required resources:

  • Allow only required destinations. Add fully qualified domain names (FQDNs) for public or private resources that your app needs. See Required egress domains for app deployment for the minimum set of domains needed for deployment.
  • Include package repositories as needed. If your app installs public Python or Node.js packages, you might need to allow domains such as pypi.org for Python, or registry.npmjs.org for Node. Your application might require additional or different domains depending on your specific dependencies. Without these repositories, app builds that rely on requirements.txt or package.json might fail.
  • Use dry-run mode to validate your network policy. This mode simulates policy enforcement without blocking traffic.
  • Review denied connection attempts using the system.access.outbound_network table. This helps you identify domains that you might need to allow. See Check denial logs.
  • Add any required external domains, such as trusted APIs or Azure storage accounts not registered in Unity Catalog.

If your workspace uses front-end private connectivity, you must complete additional configuration steps to deploy and use Databricks apps. Without this configuration, app deployments might fail or users might be unable to reach the app.

DNS configuration

You must configure conditional DNS forwarding for the databricksapps.com domain so that app URLs resolve to private IP addresses instead of public IP addresses. Without this configuration, users behind a private network can't reach deployed apps.

Add conditional forwarding rules for the following domains to your Azure DNS server:

  • *.databricksapps.com
  • *.azuredatabricks.net
  • *.privatelink.azuredatabricks.net

Verify that your VNet links to the Azure Private DNS Zone. For detailed DNS setup instructions, see Custom DNS configuration.

Egress requirements

In Private Link environments with restricted egress, apps require outbound connectivity to specific domains during both build time and runtime. See Required egress domains for app deployment for the full list of domains to allowlist.

To configure egress for apps in a Private Link environment:

  1. Create or update a network connectivity configuration (NCC) and attach it to the workspace hosting your app.
  2. Create or update a network policy to allowlist the required domains.
  3. Use dry-run mode first to validate your configuration without blocking traffic.
  4. Review the system.access.outbound_network system table for any denied connection attempts during app deployment.

If your app fails to deploy in a Private Link environment:

  1. Check egress denial logs. Query the system.access.outbound_network system table for recent denial events. See Check denial logs.

    SELECT *
    FROM system.access.outbound_network
    WHERE event_time >= CURRENT_TIMESTAMP() - INTERVAL 2 HOUR
    ORDER BY event_time DESC;
    
  2. Verify DNS resolution. Confirm that your app's URL resolves to a private IP address, not a public IP address. Use nslookup from within your private network to check:

    nslookup <your-app-name>.databricksapps.com
    
  3. Review network policy configuration. Verify the required domains are in the allowlist. Missing domains for package repositories (pypi.org, registry.npmjs.org) are the most common cause of build failures.

  4. Restart the app. After updating network policies, redeploy or restart the app so the updated policies take effect. See Restart or redeploy serverless workloads.

Encryption and traffic routing

Databricks Apps uses dedicated routing paths and multiple encryption layers to secure network communications and protect data.

Traffic routing

Traffic between the Azure Databricks control plane, compute plane, other Azure Databricks resources, and cloud services travels over the cloud provider's global network and doesn't traverse the public internet.

Traffic between users and databricksapps.com might traverse the public internet depending on the user's network location. To avoid public internet routing, configure front-end private connectivity.

Encryption in transit

All network communications to and from apps are encrypted:

  • User traffic: Communication between users and databricksapps.com uses Transport Layer Security (TLS) 1.3 encryption.
  • Control plane traffic: Communication between the Azure Databricks control plane and compute plane uses mutual TLS (mTLS) for management operations including app creation, updates, and deletion.

Encryption at rest

Databricks Apps encrypts stored data using the following methods:

  • Application code: Azure Databricks stores app code in workspace files and uses the same encryption as notebooks and other workspace files.
  • Compute storage: Apps use ephemeral host operating system disks encrypted with AES-256 and the cloud provider's default encryption implementation.