Secure cluster connectivity

  • Article

When secure cluster connectivity is enabled, customer virtual networks have no open ports and compute resources in the classic compute plane have no public IP addresses. Secure cluster connectivity is also known as No Public IP (NPIP).

  • At a network level, each cluster initiates a connection to the control plane secure cluster connectivity relay during cluster creation. The cluster establishes this connection using port 443 (HTTPS) and uses a different IP address than is used for the Web application and REST API.
  • When the control plane logically starts new Databricks Runtime jobs or performs other cluster administration tasks, these requests are sent to the cluster through this tunnel.
  • The compute plane (the VNet) has no open ports, and classic compute plane resources have no public IP addresses.

Benefits:

  • Easy network administration, with no need to configure ports on security groups or to configure network peering.
  • With enhanced security and simple network administration, information security teams can expedite approval of Databricks as a PaaS provider.

Note

All Azure Databricks network traffic between the classic compute plane VNet and the Azure Databricks control plane goes across the Microsoft network backbone, not the public Internet. This is true even if secure cluster connectivity is disabled.

Secure cluster connectivity

Use secure cluster connectivity

To use secure cluster connectivity with a new Azure Databricks workspace, use any of the following options.

  • Azure Portal: When you provision the workspace, go to the Networking tab and set the option Deploy Azure Databricks workspace with Secure Cluster Connectivity (No Public IP) to Yes.
  • ARM Templates: For the Microsoft.Databricks/workspaces resource that creates your new workspace, set the enableNoPublicIp Boolean parameter to true.

Important

In either case, you must register the Azure Resource Provider Microsoft.ManagedIdentity in the Azure subscription that is used to launch workspaces with secure cluster connectivity. This is a one-time operation per subscription. For instructions, see Azure resource providers and types.

You can add secure cluster connectivity to an existing workspace that already uses VNet injection. See Add secure cluster connectivity to an existing workspace.

If you're using ARM templates, add the parameter to one of the following templates, based on whether you want Azure Databricks to create a default (managed) virtual network for the workspace, or if you want to use your own virtual network, also known as VNet injection. VNet injection is an optional feature that allows you to provide your own VNet to host new Azure Databricks clusters.

Egress from workspace subnets

When you enable secure cluster connectivity, both of your workspace subnets are private subnets, since cluster nodes do not have public IP addresses.

The implementation details of network egress vary based on whether you use the default (managed) VNet or whether you use the optional VNet injection feature to provide your own VNet in which to deploy your workspace. See the following sections for details.

Important

Additional costs may be incurred due to increased egress traffic when you use secure cluster connectivity. For a smaller organization that needs a cost-optimized solution, it may be acceptable to disable secure cluster connectivity when you deploy your workspace. However, for the most secure deployment, Azure and Databricks strongly recommend that you enable secure cluster connectivity.

Egress with default (managed) VNet

If you use secure cluster connectivity with the default VNet that Azure Databricks creates, Azure Databricks automatically creates a NAT gateway for outbound traffic from your workspace's subnets to the Azure backbone and public network. The NAT gateway is created within the managed resource group managed by Azure Databricks. You cannot modify this resource group or any resources provisioned within it.

The automatically-created NAT gateway incurs additional cost.

Egress with VNet injection

If you enable secure cluster connectivity on your workspace that uses VNet injection, Databricks recommends that your workspace has a stable egress public IP.

Stable egress public IP addresses are useful because you can add them to external allow lists. For example, to connect from Azure Databricks to Salesforce with a stable outgoing IP address.

Warning

Azure announced that on September 30, 2025, default outbound access connectivity for virtual machines in Azure will be retired. See this announcement. This means that existing Azure Databricks workspaces that use default outbound access rather than a stable egress public IP might not continue to work after that date. Databricks recommends that you add explicit outbound methods for your workspaces before that date.

Choose one of the following options:

  • For deployments that need some customization, choose an Azure NAT gateway. Configure the gateway on both of the workspace's subnets to ensure that all outbound traffic to the Azure backbone and public network transits through it. Clusters have a stable egress public IP, and you can modify the configuration for custom egress needs. You can implement this solution using either an Azure template or from the Azure portal.
  • For deployments with complex routing requirements or deployments that use VNet injection with an egress firewall such as Azure Firewall or other custom networking architectures, you can use custom routes called user-defined routes (UDRs). UDRs ensure that network traffic is routed correctly for your workspace, either directly to the required endpoints or through an egress firewall. If you use such a solution, you must add direct routes or allowed firewall rules for the Azure Databricks secure cluster connectivity relay and other required endpoints listed at User-defined route settings for Azure Databricks.

Warning

Do not use an egress load balancer with a workspace that has secure cluster connectivity enabled. In production systems, an egress load balancer can lead to risk of exhausting ports.

Add secure cluster connectivity to an existing workspace

You can enable secure cluster connectivity on an existing workspace. The upgrade requires that the workspace uses VNet injection.

You can use the portal UI, an ARM template, or azurerm Terraform provider version 3.41.0+. You can use the Azure portal to apply a custom template and modify the parameter in the UI. You can also upgrade the Azure Databricks workspace instance itself in the Azure portal UI.

Important

Before making this change, if you use a firewall or did other network configuration changes to control ingress or egress from the classic compute plane, you may need to update your firewall or network security group rules at the same time as these changes for them to fully take effect. For example, with secure cluster connectivity, there is an additional outgoing connection to the control plane, and the incoming connections from the control plane are no longer used.

If something goes wrong with the upgrade and you need to temporarily rollback the change, see Temporary rollback of upgrading to secure cluster connectivity.

Step 1: Stop all compute resources

Before attempting this upgrade, you must stop all compute resources such as clusters, pools, or classic SQL warehouses. No workspace compute resources can be running or the upgrade attempt fails. Databricks recommends planning the timing of the upgrade for down time.

Step 2: Update the workspace

You must update the No Public IP parameter (on the template it is enableNoPublicIp). Set it to the value True (true).

Use one of these methods:

Use Azure portal UI (with no template)

  1. Go to your Azure Databricks Service instance in the Azure portal.

  2. In the left navigation under Settings, click Networking.

  3. Select No Public IP.

    Note

    At the same time, you can choose to also enable Azure Private Link by setting the values for Allow Public Network Access Required NSG Rules to the appropriate values for your use case. However, additional configuration and verification is required to enable Private Link, so you may want to do that as a separate step after this update for secure cluster connectivity. For important details and requirements, see enable Azure Private Link.

  4. Click Save.

The network update might take over 15 minutes to complete.

Apply an updated ARM template using Azure portal

Note

If your managed resource group has a custom name, you must modify the template accordingly. Contact your Azure Databricks account team for more information.

  1. Copy the following upgrade ARM template JSON:

      {
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "location": {
            "defaultValue": "[resourceGroup().location]",
            "type": "String",
            "metadata": {
                "description": "Location for all resources."
            }
        },
        "workspaceName": {
            "type": "String",
            "metadata": {
                "description": "The name of the Azure Databricks workspace to create."
            }
        },
        "apiVersion": {
            "defaultValue": "2023-02-01",
            "allowedValues": [
               "2018-04-01",
               "2020-02-15",
               "2022-04-01-preview",
               "2023-02-01"
            ],
            "type": "String",
            "metadata": {
                "description": "2018-03-15 for 'full region isolation control plane' and 2020-02-15 for 'FedRAMP certified' regions"
            }
        },
        "enableNoPublicIp": {
            "defaultValue": true,
            "type": "Bool"
        },
        "pricingTier": {
            "defaultValue": "premium",
            "allowedValues": [
                "premium",
                "standard",
                "trial"
            ],
            "type": "String",
            "metadata": {
                "description": "The pricing tier of workspace."
            }
        },
        "publicNetworkAccess": {
          "type": "string",
          "defaultValue": "Enabled",
          "allowedValues": [
            "Enabled",
            "Disabled"
          ],
          "metadata": {
            "description": "Indicates whether public network access is allowed to the workspace - possible values are Enabled or Disabled."
          }
        },
        "requiredNsgRules": {
          "type": "string",
          "defaultValue": "AllRules",
          "allowedValues": [
            "AllRules",
            "NoAzureDatabricksRules"
          ],
          "metadata": {
            "description": "Indicates whether to retain or remove the AzureDatabricks outbound NSG rule - possible values are AllRules or NoAzureDatabricksRules."
          }
        }
    },
    "variables": {
        "managedResourceGroupName": "[concat('databricks-rg-', parameters('workspaceName'), '-', uniqueString(parameters('workspaceName'), resourceGroup().id))]",
        "managedResourceGroupId": "[subscriptionResourceId('Microsoft.Resources/resourceGroups', variables('managedResourceGroupName'))]"
    },
    "resources": [
        {
            "type": "Microsoft.Databricks/workspaces",
            "apiVersion": "[parameters('apiVersion')]",
            "name": "[parameters('workspaceName')]",
            "location": "[parameters('location')]",
            "sku": {
                "name": "[parameters('pricingTier')]"
            },
            "properties": {
                "ManagedResourceGroupId": "[variables('managedResourceGroupId')]",
                "publicNetworkAccess": "[parameters('publicNetworkAccess')]",
                "requiredNsgRules": "[parameters('requiredNsgRules')]",
                "parameters": {
                    "enableNoPublicIp": {
                        "value": "[parameters('enableNoPublicIp')]"
                    }
                }
            }
        }
    ]
}

    1. Go to the Azure portal Custom deployment page.

    2. Click Build your own template in the editor.

    3. Paste in the JSON for the template that you copied.

    4. Click Save.

    5. Fill in the parameters.

    6. To update an existing workspace, use the same parameters that you used to create the workspace other than enableNoPublicIp which you must set to true. Set the subscription, region, workspace name, subnet names, resource ID of the existing VNet.

      Important

      The resource group name, workspace name, and subnet names are identical to your existing workspace so that this command updates the existing workspace rather than creating a new workspace.

    7. Click Review + Create.

    8. If there are no validation issues, click Create.

    The network update might take over 15 minutes to complete.

Apply an update using Terraform

For workspaces created with Terraform, you can update the workspace without recreating the workspace.

Important

You must use terraform-provider-azurerm version 3.41.0 or later, so upgrade your Terraform provider version as needed. Earlier versions attempt to recreate the workspace if you change any of these settings.

Change the following workspace settings:

  • no_public_ip in the custom_parameters block can be changed from false to true.

The network update might take over 15 minutes to complete.

Step 3: Validate the update

Once the workspace is in active state, the update job is completed. Verify that the update was applied:

  1. Open Azure Databricks in your web browser.

  2. Start one of the workspace's clusters and wait until the cluster is fully started.

  3. Go to your workspace instance in the Azure portal.

  4. Click the blue ID next to the field label Managed Resource Group.

  5. In that group, find the VMs for the cluster and click on one of them.

  6. In the VM settings, within Properties, look for the fields in the Networking area.

  7. Confirm that the Public IP address field is empty.

    If it's populated, the VM has a public IP address, which means the update failed.

Failure recovery

If a workspace update fails, the workspace might be marked as a Failed state, which means that the workspace is unable to perform compute operations. To restore a failed workspace back to Active state, review the instructions in the status message of the update operation. Once you fix any issues, redo the update on the failed workspace. Repeat the steps until the update successfully completes.

Temporary rollback of upgrading to secure cluster connectivity

If something goes wrong during deployment you can reverse the process as a temporary rollback, but disabling SCC on a workspace is unsupported other than for temporary rollback before continuing the upgrade later. If this is necessary temporarily, you can follow the instructions above for upgrade but set enableNoPublicIp to false instead of true.