Skip to main content
Last updated on

Context-based network policies

Databricks context-based policies provide a unified security framework for managing both inbound and outbound traffic to your workspaces. With context-based ingress, administrators can restrict workspace access based on a combination of identity, network source, and request type. Serverless egress policies extend this control to outbound traffic by limiting serverless workloads to authorized destinations. Together, these network policies help ensure that both user access and data movement remain within trusted boundaries across your organization.

Context-based network policies complement these existing security features:

  • Context-based ingress control:
    • Workspace IP access lists
    • Account IP access lists
    • Inbound Private Service Connect
    • Outbound Private Service Connect
  • Serverless egress control:
    • Network connectivity configurations (NCCs)

Benefits​

Context-based ingress network policies provide the following benefits to your network security:

  • Enhanced security: Mitigate unauthorized access and data exfiltration risks.
  • Identity-aware control: Support SaaS clients without stable IP ranges by using identity-based rules.
  • Flexible enforcement: Apply different rules to different request types, sources, and identities.
  • Centralized management: Configure once at the account level, apply across multiple workspaces.
  • Safe testing: Use dry run mode to test policy impacts before full enforcement.

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 Databricks workspace endpoints.

Outbound connections from Serverless compute to external destinations.

Primary use case

Restrict who can access your workspace, 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)

Access type (Workspace UI, API, Apps, Lakebase Compute)

Allowed locations

FQDNs

Cloud storage containers

Audit logging

system.access.inbound_network system table

system.access.outbound_network system table

How context-based policies work​

With ingress control, you can:

  • Stop access from untrusted networks by requiring both valid credentials and a trusted network source.
  • Allow SaaS automation tools with dynamic IPs by using identity-based rules instead of IP allowlists.
  • Restrict sensitive operations to the workspace UI while allowing broader API access.
  • Limit high-privilege service principals to corporate network ranges only.

With egress control, you can:

  • Prevent data exfiltration by restricting which external APIs Serverless compute can reach.
  • Allow connectivity only to approved cloud storage buckets and external databases.
  • Block outbound connections to unauthorized destinations while permitting required integrations.
  • Enforce compliance by limiting data movement to approved regions and services.
    • Configure ingress policies
    • Set up allow and deny rules that combine identity, network source, and access type to control inbound requests to your workspace.
    • Configure egress policies
    • Define outbound connection rules to control which external destinations your Serverless compute resources can reach.

Enforcement modes​

Context-based policies have two different modes of enforcement:

  • Enforced mode: Rules are actively applied. Violating requests are blocked.
  • Dry run mode: Violations are logged but not blocked. Use this mode to test policy impacts before enforcement.

Databricks recommends starting with dry run mode to avoid unintended access disruptions.

Audit logging​

Databricks logs all policy evaluations for compliance and monitoring:

Query these logs to validate policy effectiveness and detect unauthorized access attempts.

How policies interact with other controls​

  • IP access lists: Both IP access lists and ingress policies must allow a request. If you disable public access in your private access settings, the system denies all public requests regardless of ingress policy rules.
  • Private connectivity: Works alongside ingress policies when public access is enabled.
  • Security profiles: Context-based policies provide network-level controls that complement compute and data governance.

Best practices​

  • Start with dry run mode to validate policy behavior before enforcement.
  • Use identity-based rules for SaaS clients with dynamic IP addresses.
  • Apply deny rules to high-privilege service principals first to limit risk.
  • Monitor audit logs regularly to detect unexpected access patterns.
  • Test egress policies to ensure required external resources remain accessible.
  • Use descriptive policy names for long-term maintainability.