Azure Databricks IP access lists: restricting workspace access by network without locking yourself out

#What IP access lists do

IP access lists restrict which public IP addresses can reach a workspace's web UI and REST APIs. They apply to the public front end. They don't replace Private Link, but on workspaces that keep public access they are a simple, effective control.

• Allow lists: if any allow list exists, only those IPs are permitted.
• Block lists: always denied, checked first, even if an allow list also matches.
• The feature needs the Premium tier and is off until you enable it.
• The account console has its own, separate IP access lists.

#Step 1: collect every source IP first

Before enabling anything, list every place that calls the workspace:

Check who is calling today from the audit logs if they are enabled (system.access.audit):

SELECT source_ip_address, user_identity.email, count(*) AS calls
FROM system.access.audit
WHERE event_date >= current_date() - 14
GROUP BY ALL
ORDER BY calls DESC;

Caution

Enabling an allow list that doesn't include your own IP blocks you from the UI and the API that could undo it. Always add your current IP and test from a second session before closing the first.

#Step 2: create the lists, then enable the feature

Authenticate the CLI to the workspace (OAuth or Entra ID token), then create lists before turning enforcement on:

databricks ip-access-lists create --json '{
  "label": "office-and-vpn",
  "list_type": "ALLOW",
  "ip_addresses": ["203.0.113.0/24", "198.51.100.17/32"]
}'

databricks ip-access-lists create --json '{
  "label": "ci-cd-agents",
  "list_type": "ALLOW",
  "ip_addresses": ["192.0.2.40/32"]
}'

databricks ip-access-lists list

Enable enforcement:

databricks workspace-conf set-status --json '{"enableIpAccessLists": "true"}'
databricks workspace-conf get-status enableIpAccessLists

The same with the REST API:

curl -X PATCH "$DATABRICKS_HOST/api/2.0/workspace-conf" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"enableIpAccessLists": "true"}'

curl -X POST "$DATABRICKS_HOST/api/2.0/ip-access-lists" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"label": "office-and-vpn", "list_type": "ALLOW", "ip_addresses": ["203.0.113.0/24"]}'

Changes can take a few minutes to apply.

#Step 3: maintain the lists

# Replace the addresses in an existing list (get the list_id from 'list')
databricks ip-access-lists replace <list-id> --json '{
  "label": "office-and-vpn", "list_type": "ALLOW", "enabled": true,
  "ip_addresses": ["203.0.113.0/24", "198.51.100.17/32", "198.51.100.18/32"]
}'

# Temporarily disable one list without deleting it
databricks ip-access-lists update <list-id> --json '{"enabled": false}'

# Delete
databricks ip-access-lists delete <list-id>

Block a known bad range:

databricks ip-access-lists create --json '{
  "label": "blocked", "list_type": "BLOCK", "ip_addresses": ["192.0.2.0/24"]
}'

Exact flags vary between CLI versions; check databricks ip-access-lists --help.

#Troubleshooting

The error users see in the browser or API response is similar to: "Source IP address: x.x.x.x is blocked by Databricks IP ACL for workspace: ...".

#Prevent it next time

• Keep IP lists in Terraform (databricks_ip_access_list and databricks_workspace_conf) so changes are reviewed.
• Add a "break-glass" allow entry for a jump host with a fixed IP that admins can always use.
• Label lists by purpose and keep a comment with the owner for each range.
• Re-check the audit log monthly for blocked attempts; repeated blocks from your own ranges mean the list is out of date.
• For workspaces with sensitive data, plan the move to front-end Private Link and disable public access.