Hardened connectivity

Hardened connectivity builds on Managed security to add layered ingress and egress controls: context-based ingress (CBI), VPC endpoints, serverless egress controls, and an optional external firewall. Workspace access stays on the public internet, gated by CBI.

This architecture has:

  • Context-based workspace ingress: Users sign in over the internet, and CBI policies restrict workspace access by network source, identity, authentication mechanism, and access scope. This is a simplicity trade-off compared to VPN-gated architectures.
  • Private cloud service access: VPC endpoints (AWS) or service endpoints (Azure) keep cloud service traffic off the public internet.
  • Serverless egress control: Network policies and NCC private endpoints govern outbound traffic from serverless compute.
  • Optional egress inspection: Deploy an external firewall to inspect and log classic compute egress.
  • No VPN required: Simplified user access without corporate network dependency.

Use this architecture when:

  • Data security is the primary concern, not workspace access control.
  • VPN complexity is a barrier to user productivity.
  • IP-based access controls are sufficient for compliance.
  • Your organization prefers cloud-first access patterns.

Prerequisites

  • Azure Azure Databricks Premium tier with a VNet-injected workspace.
  • List of IP ranges for workspace access control.

Architecture overview

The Hardened connectivity architecture secures network traffic and simplifies user access:

Traffic type Path
User access Users → Internet → CBI policy → Workspace
Classic compute → control Compute → Classic Private Link → Azure Databricks control plane
Classic compute → cloud Compute → Service endpoints or UDRs → Azure services
Serverless → your resources Serverless compute → NCC private endpoints → Your Azure resources
Classic compute → egress Compute → External firewall (optional) → Inspected internet

Note

Workspace access is not private in this architecture. Users connect over the public internet, restricted by CBI policies. If your organization requires private workspace access, use the Isolated environment architecture instead.

Required components

Inbound

No inbound Private Link. Public internet access is restricted by context-based ingress policies and, optionally, IP access lists. Follow standard IAM for authentication. See Authentication and access control.

User shield icon. Workspace ingress controls

Configure workspace ingress through context-based ingress (CBI), the recommended ingress policy framework. CBI rules combine network source (IP ranges), identity, authentication mechanism, and access scope into a single allow/deny model, so the network-source attribute does the same job as the standalone IP access list feature, plus more.

IP access lists remain supported and can be configured alongside CBI. When both are configured, a request must be allowed by both controls.

Configuration levels:

Best practices:

  • Start broad, refine based on actual usage.
  • Document IP ranges with purpose and expiration dates.
  • Maintain administrator access through a known-good IP range.
  • Review quarterly and remove obsolete ranges.

Warning

Ingress policies and IP access lists can lock you out of your workspace if misconfigured. Always maintain administrator access through a known-good IP range.

Lock share icon. Delta Sharing recipient access control

Delta Sharing uses its own IP access lists configured on recipient objects. This is separate from context-based ingress and workspace IP access lists. Applies to open sharing (non-Azure Databricks recipients) only.

See Restrict Delta Sharing recipient access using IP access lists (open sharing).

Outbound

Serverless egress is governed by network policies and NCC private endpoints. Classic compute egress can optionally flow through an external firewall for inspection. Use Unity Catalog for data governance of outbound data access. See What is Unity Catalog?.

Filter icon. Serverless egress control

Configure network policies to control serverless compute outbound traffic. Define allowed destinations using IP ranges or FQDNs.

See What is serverless egress control?.

Link icon. Serverless Private Link (NCC private endpoints)

Provides private connectivity from serverless compute to your resources through Private Link. Serverless data traffic stays off the public internet.

See Configure private connectivity to Azure resources.

Shield icon. External firewall for classic compute (optional)

Route classic compute egress through an external firewall for inspection, logging, and policy enforcement. Required in Isolated environment; optional here.

Options include Azure Firewall or a third-party network virtual appliance (NVA).

Warning

Azure Databricks control plane and SCC relay connections use TLS with certificate pinning. Do not enable TLS inspection (decrypt and re-encrypt) on traffic between your clusters and the Azure Databricks control plane. Doing so causes cluster failures. See IP addresses and domains for Azure Databricks services and assets for required endpoints.

Classic compute baseline

The classic compute baseline is inherited from Managed security. No additional classic compute components are required for this architecture.

The baseline includes VNet injection, Secure Cluster Connectivity (SCC), and classic Private Link.

Note

This architecture doesn't use inbound Private Link. Users access the workspace over the public internet, controlled by CBI policies. If your organization requires private workspace access, see the Isolated environment architecture, which adds inbound Private Link or VPN-gated access.

Arrows connect icon. User-defined routes

Configure routing for cloud service access to keep traffic private and reduce costs.

Configure UDRs with service tags for Azure services. See User-defined route settings for Azure Databricks.

Implementation

Start from a deployed Managed security baseline. The following phases add the ingress and egress controls that define this architecture.

Phase 1: Inbound access control

  1. Configure account-level context-based ingress (CBI) policies to restrict workspace access by network source, identity, authentication mechanism, and access scope. See Context-based ingress control and Manage context-based ingress policies.
  2. Optionally, configure workspace-level IP access lists alongside CBI for backwards compatibility or per-workspace overrides. When both are configured, a request must be allowed by both. See Configure IP access lists for workspaces.
  3. Configure account-level IP access lists to control access to the account console. See Configure IP access lists for the account console.
  4. If you use Delta Sharing open sharing, configure recipient-level IP access lists on each share recipient. See Restrict Delta Sharing recipient access using IP access lists (open sharing).
  5. Maintain documentation for all configured IP ranges, including justification, linked tickets, and planned review dates.
  6. Verify access behavior by testing sign-in from approved IP ranges and confirming that connections from non-approved IP ranges are blocked.

Phase 2: Cloud service endpoints

  1. Configure user-defined routes (UDRs) using Azure service tags so traffic to Azure services follows your desired private or controlled egress paths. See User-defined route settings for Azure Databricks.
  2. Configure service endpoints or private endpoints for customer-managed Azure storage accounts as required.

Phase 3: Serverless egress controls

  1. Configure serverless network policies to restrict serverless compute outbound traffic to approved destinations using IP ranges or FQDNs. See What is serverless egress control?.
  2. Configure NCC private endpoints for private connectivity from serverless compute to your Azure resources. See Configure private connectivity to Azure resources.
  3. Test that serverless workloads can reach approved destinations and are blocked from unapproved ones.

Phase 4 (optional): External firewall for classic compute

  1. Deploy Azure Firewall or a third-party network virtual appliance (NVA) in a hub VNet and peer it with the workspace VNet.
  2. Configure UDRs in the workspace subnets with a default route to the firewall.
  3. Configure firewall rules to allow required Azure Databricks endpoints without TLS interception on control plane and SCC relay traffic.

The Azure Databricks Terraform SRA provides Infrastructure-as-Code templates that automate this deployment.

Validation

After you deploy the architecture, run the following checks to confirm classic compute plane traffic stays private and that your IP access list restricts workspace access as configured.

Check Expected result
Workspace accessible from allowed IPs Yes
Workspace blocked from unauthorized IPs Yes
Clusters launch with SCC Yes, no public IPs
Data access through private connections Yes
Package installation from private artifact repos Yes

Troubleshooting

If a validation check fails or a workload behaves unexpectedly, use the following table to diagnose common issues.

Issue Cause Resolution
Can't access workspace IP not in access list Add IP to workspace list
Cluster fails to start Routing or endpoint misconfiguration Check route tables and private endpoint connectivity
S3/ADLS access fails VPC endpoint or routing issue Check endpoint configuration and security groups
Package installation fails Private artifact repository unreachable Check VNet endpoint configuration and DNS resolution for your artifact repository
Intermittent access issues Dynamic IP addresses Use VPN with static egress IP or widen IP ranges

Ongoing maintenance

  • IP access list management: Review monthly, add new locations, remove obsolete ranges.
  • Endpoint monitoring: Track private endpoint health and data transfer costs.
  • Artifact repository management: Maintain private package mirrors and monitor availability.
  • User support: Maintain process for IP access issues.

Previous and next steps

Architecture When to choose
Managed security Previous step. If IP-based access controls, VPC endpoints, and serverless egress controls are more than your workloads require. The baseline includes customer-managed VNet, SCC, and classic Private Link.
Isolated environment Next step. If IP-based access control proves insufficient, regulations require private workspace access, or compliance requires data exfiltration prevention.
  • Last updated on