Databricks subnets should have a network security group attached

A network security group is the basic Azure traffic filter for a subnet: a list of allow and deny rules for inbound and outbound connections. Databricks workspaces deployed into your own virtual network need one on each of their two subnets, and Microsoft lists this as a requirement in Deploy Azure Databricks in your Azure virtual network.

Without a group on a subnet, you rely on defaults and lose the chance to limit which sources can reach the cluster machines and which destinations they can call. That weakens your ability to contain a compromised cluster or a mistaken job that reaches somewhere it should not.

In the Azure portal, open Virtual networks, select the network used by the workspace, choose Subnets and check the Security group column for the two Databricks subnets. Both should show a group name.

From the command line (read-only):

az network vnet subnet show --resource-group <resource-group> --vnet-name <vnet-name> \
  --name <subnet-name> --query "{subnet:name, nsg:networkSecurityGroup.id, delegation:delegations[0].serviceName}" -o json

An nsg value of null means no group is attached. Run it once for the host subnet and once for the container subnet.

Portal steps:

• Open Network security groups and create a group in the same region as the virtual network (or reuse the one already meant for Databricks).
• Open the virtual network, go to Subnets, select a Databricks subnet and set Network security group to that group. Repeat for the second subnet.
• Keep the rules that Databricks creates and needs. Add your own rules at a different priority instead of editing the managed ones.

Script (this changes your Azure when you run it; ConfigCobra itself stays read-only):

az network nsg create --resource-group <resource-group> --name <nsg-name> --location <region>
az network vnet subnet update --resource-group <resource-group> --vnet-name <vnet-name> \
  --name <subnet-name> --network-security-group <nsg-name>

Databricks may also manage rules on the group for workspaces created with secure cluster connectivity, so check the Microsoft Learn page above for the current rule list.

Attaching a group is quick and does not restart anything by itself, but the rules inside it decide what clusters can reach. If a group is attached with deny rules that block the Databricks control plane, storage or your data sources, new clusters can fail to start and running jobs can lose connectivity.

Start with the rule set Databricks documents, add restrictions one at a time and test with a small cluster. The teams affected are the platform engineers who own the network and the data teams whose jobs depend on outbound access. ConfigCobra's remediation impact analysis shows the affected resources before you apply the change.