Context-based ingress control

Important

This feature is in Public Preview.

Note

This feature requires the Premium tier.

This page provides an overview of context-based ingress control. For serverless egress control, see What is serverless egress control?.

To configure ingress policies, see Manage context-based ingress policies.

Context-based ingress control overview

Context-based ingress control works alongside IP access lists and frontend private connectivity to enable account admins to set allow and deny rules that combine who is calling, from where they are calling, and what they can reach in Azure Databricks. This ensures that only trusted combinations of identity, request type, and network source can reach your workspace. Context-based ingress control is configured at the account level. A single policy can govern multiple workspaces.

Using context-based ingress, you can:

• Stop access from untrusted networks by requiring a second factor, a trusted network source, in addition to credentials.
• Allow access for 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 like Azure Databricks APIs or the workspace UI.
• Protect privileged automation: Constrain high-value service principals to high-trust networks only.
• Audit effectively: Capture detailed denial logs in Unity Catalog system tables to monitor blocked requests.

Context-based ingress control core concepts

Network sources

A network source defines the origin of requests. Supported types include:

• All public IPs: Any public internet source.
• Selected IPs: Specific IPv4 addresses or CIDR ranges.

Access types

Rules apply to different incoming request scopes. Each scope represents a category of incoming requests that you can allow or deny:

• Workspace UI: Browser access to the workspace.
• API: Programmatic access through Azure Databricks APIs, including SQL endpoints (JDBC / ODBC). You can target all APIs or a specific API scope, such as apps, dashboard, or model serving.
• Apps: Allow or deny access to Databricks Apps deployments. See Databricks Apps. Only the All users and service principals identity option is supported for this access type.

• Lakebase Compute: Connections to Lakebase database instances. See Lakebase instances. Only the All users and service principals identity option is supported for this access type.

Identities

Rules can target different identity types. For the Apps and Lakebase Compute access types, the only supported option is All users and service principals.

• All users and service principals: Both human users and automation.
• All users: Human users only.
• All service principals: Automation identities only.
• Selected identities: Specific users or service principals chosen by the administrator.

Rule evaluation

• Default deny: In restricted mode, access is denied unless explicitly allowed.
• Deny before allow: Deny rules let you define exceptions to your allow rules.
• Default policy: Each account has a default ingress policy applied to all eligible workspaces without an explicit policy assignment.

Enforcement modes

Context-based ingress policies enable two modes:

• Enforced for all products: Azure Databricks actively applies rules and blocks violating requests.
• Dry run mode for all products: Azure Databricks logs violations but does not block requests. Use this mode to evaluate policy impact before enforcing.

Note

A network policy supports only one enforcement mode at a time.

Auditing

Denied or dry-run requests are logged in the system.access.inbound_network system table. Each log entry includes:

• Event time
• Workspace ID
• Request type
• Identity
• Network source
• Access type (DENIED or DRY_RUN_DENIAL)

Query these logs to verify your rules work as expected and to catch unexpected access attempts.

Relationship with other controls

• Workspace IP access lists: Evaluated before the context-based ingress policy allows a request. Both must allow the request. Workspace IP access lists can further narrow access but cannot widen it.
• Serverless egress control: Complements ingress policies by controlling outbound network traffic from serverless compute. See Manage network policies.

• Front-end private connectivity: Enforced alongside ingress policies when Allow Public Network Access is Enabled. If Allow Public Network Access is Disabled, all public ingress is blocked and ingress policies are not evaluated. See Configure Inbound Private Link.

Best practices

• Begin with dry run mode to observe impacts without breaking access.
• Use identity-based rules where possible for SaaS clients that rotate IPs.
• Apply deny rules to privileged service principals first to limit affected area.
• Keep policy names clear and consistent.

Note

Context-based ingress control is not available in the Azure West India region.