Context-based network policies

Azure Databricks context-based network policies provide a unified security framework for managing both inbound and outbound traffic to your workspaces and account-level resources (for example, the account console and account-level Genie One).

Azure Databricks supports two types of context-based control:

• Context-based ingress control: Restricts who can reach your resources, from where, and what they can access, based on a combination of identity, network source, and request type.
• Serverless egress control: Restricts where your serverless workloads can send data by limiting outbound connections to authorized destinations.

Context-based network policies overview

Context-based network policies let account admins set allow and deny rules that combine who is calling, from where they are calling, and what they can reach, and control which external destinations serverless workloads can connect to. This helps you meet security and compliance requirements and reduces the risk of unauthorized access and data exfiltration.

Workspace-level policies are configured under Workspace level policies, with a default workspace-level policy assigned to all workspaces without an explicit assignment. The account-level policy is configured separately under Account level policy; its policy ID is account-policy.

With context-based network policies, you can:

• Stop access from untrusted networks by requiring a trusted network source in addition to credentials.
• Allow access for software as a service (SaaS) clients without stable egress IPs by keying on identity instead of IP ranges.
• Limit access by allowing less trusted sources to use only certain scopes, such as Azure Databricks APIs or the workspace UI.
• Enforce a deny-by-default posture for outbound connections from serverless workloads.
• Audit effectively by capturing detailed denial logs in Unity Catalog system tables.

Context-based network policies complement these existing security features:

• Context-based ingress control:
  • Workspace IP access lists
  • Account IP access lists
  • Inbound Private Link (using private access settings)
• Serverless egress control:
  • Outbound Private Link (using network connectivity configurations)

Policy types compared

Context-based network policies include two types: ingress control and egress control. The following table summarizes the key differences:

Attribute	Ingress control	Egress control
What it controls	Inbound requests to Azure Databricks workspace and account-level endpoints.	Outbound connections from Serverless compute to external destinations.
Primary use case	Restrict who can access your workspace and account-level resources, from where, and what they can reach.	Prevent data exfiltration by controlling which external resources Serverless compute can connect to.
Policy criteria	Identity (multiple users or multiple service principals) Network source (CIDR range, registered private endpoints) Access type: for workspaces (Workspace UI, API, Apps runtime, Lakebase runtime); for account (Account UI, Account API)	Allowed locations FQDNs Cloud storage containers
Audit logging	system.access.inbound_network system table	system.access.outbound_network system table

Context-based ingress control

Context-based ingress control lets account admins set allow and deny rules that combine identity, network source, and request type, so only trusted combinations can reach your resources.

Workspace-level policies govern access to workspaces, and a single account-level policy (account-policy) governs account-level resources such as the account console and account-level Genie One. Each account includes a default workspace-level policy that applies to all eligible workspaces without an explicit assignment.

For network sources, access types, identities, rule evaluation, enforcement modes, auditing, and how ingress interacts with other network controls, see Context-based ingress control.

Serverless egress control

Serverless egress control manages outbound network connections from your serverless compute resources, reducing the risk of data exfiltration. A network policy is an account-level object, attached to one or more workspaces, that sets the outbound access mode for serverless workloads:

• Full access: Serverless workloads have unrestricted outbound access to the internet and other network resources.
• Restricted access: Outbound access is limited to Unity Catalog external locations plus the FQDNs and Azure storage account you explicitly list in the policy.

For the restricted-access security posture, supported serverless products, and configuration steps, see What is serverless egress control?.

Enforcement modes

Both ingress and egress policies support Enforced mode, in which rules are applied and violating requests are blocked, and Dry run mode, in which violations are logged but not blocked. Databricks recommends starting in dry run mode to avoid unintended access disruptions.

Audit logging

Azure Databricks logs policy evaluations for compliance and monitoring: ingress denials in system.access.inbound_network and egress events in system.access.outbound_network. Query these logs to validate policy effectiveness and detect unauthorized access attempts.

How policies interact with other controls

Context-based ingress policies work alongside IP access lists and front-end private connectivity, and serverless egress control works alongside outbound private connectivity (using network connectivity configurations). For how ingress interacts with each of these controls, including per-cloud private connectivity behavior, see Relationship with other controls.

Tip

To reduce complexity, Databricks recommends using the context-based ingress policy as your only policy engine rather than also maintaining IP access lists. If your workspaces already have IP access lists, see Migrate workspace IP access lists to context-based ingress.