Skip to main content

Context-based ingress control

Beta

This feature is in Beta.

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 front-end 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 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, ensuring consistent enforcement across your organization.

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 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 inbound request scopes. Each scope represents a category of inbound requests that you can allow or deny:

  • Workspace UI: Browser access to the workspace.
  • API: Programmatic access through Databricks APIs, including SQL endpoints (JDBC / ODBC).
  • 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 admin.

Rule evaluation​

  • Default deny: In restricted mode, access is denied unless explicitly allowed.
  • Deny before allow: If both types of rules exist, deny rules take precedence.
  • 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 support two modes:

  • Enforced for all products: Rules are actively applied and violating requests are blocked.
  • Dry run mode for all products: Violations are logged but requests are not blocked, allowing you to evaluate policy impact safely.

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)

You can query these logs to validate that your rules are applied correctly and to detect 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 Public access enabled is True. If Public access enabled is False, all public ingress is blocked and ingress policies are not evaluated. See Manage private access settings.

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 blast radius.
  • Keep policies names clear and consistent for long-term maintainability.
Last updated on