Skip to main content
Last updated on

Configure inbound PrivateLink for workspaces

This page covers configuration steps for inbound private connectivity between users and their Databricks workspaces. To enhance the security of your workspace's serverless implementation, you must use inbound private connectivity.

Establish secure, private connections from your AWS VPCs or on-premises networks to Databricks services using inbound Private Link, which routes traffic through a VPC interface endpoint instead of the public internet.

An inbound endpoint originates from your transit VPC, typically serving as the source for user web application access. If you use Classic compute, this is usually a separate VPC from the workspace's compute plane VPC and can be connected to an on-premises network. If you have multiple Databricks accounts, you can share an inbound VPC endpoint across these accounts by registering the endpoint in each relevant Databricks account.

With inbound Private Link to workspaces:

  • Configure private access: Configure inbound Private Link connections to the Databricks web application, REST API, Databricks Apps, and Databricks Connect API.
  • Enforce private connectivity: Configure private connectivity from users to Databricks.

Inbound private connectivity

Requirements​

  • Your Databricks account is on the Enterprise plan.
  • You must have all necessary AWS permissions to set up a Databricks workspace and to create new VPC endpoints for your workspace.
  • To establish an inbound PrivateLink connection for accessing the workspace from your on-premises network, connect your on-premises network to an AWS VPC using Direct Connect or VPN.
  • Allow network traffic from all relevant address spaces within your local network to connect to your VPC endpoint using TCP port 443.

Step 1: Create VPC endpoints​

tip

For workspace private access, you can reuse any General Access VPC endpoint you've already created for inbound Private Link to your account-level resources (see Configure inbound Private Link for account-level resources). The region of this VPC endpoint does not have to match the region of your workspace. A General Access endpoint in any region can serve workspaces in any region.

To create inbound VPC endpoints in the AWS Management Console:

  1. Go to the VPC endpoints section of the AWS Management Console.
  2. In the upper right, set the region to the same region as your transit VPC region.
  3. Click Create Endpoint.
  4. When naming the endpoint, Databricks recommends including general-access, such as databricks-general-access-vpce.
  5. Under Type, select Endpoint services that use NLBs and GWLBs.
  6. In the service name field, paste the service name. Use the table in PrivateLink VPC endpoint services to find the regional service names. Copy the one labeled General Access (including REST API).
  7. Click Verify service and check that Service name verified appears in a green box. If you encounter an error that states "Service name could not be verified", verify that the regions of your VPC, subnets, and new VPC endpoint are correctly matched.
  8. In VPC, select your transit VPC.
  9. In Subnets, select a subnet.
  10. In the Security groups section, select a security group that allows inbound traffic on port 443 from the IP ranges that need to access the workspace.
  11. Click Create endpoint.

Step 2: Register VPC endpoints​

After you create your VPC endpoints in the AWS Management Console, register them with Databricks.

  1. Go to the Databricks account console.

  2. Click Security in the sidebar.

  3. Click Private endpoints from the vertical navigation.

  4. Click Register a private endpoint.

  5. Enter a descriptive name for your VPC endpoint registration.

    • A naming convention that includes the purpose is recommended, such as VPCE for General Access.

  6. Select the appropriate region. The region must match the region of the AWS VPC endpoint you're registering.

  7. Paste the AWS VPC endpoint ID in the AWS VPC endpoint ID field.

    Register VPC Endpoint.

  8. Click Register new VPC endpoint.

If you use Classic compute and have multiple workspaces that share the same customer-managed VPC, you can share AWS VPC endpoints among them. For multiple Databricks accounts, you can register the AWS VPC endpoint in each account.

Step 3: Configure private access policy​

Once you've registered your General Access VPC endpoint, there are two ways to configure a private access policy for your workspace: with context-based ingress, or with private access settings. Using the context-based ingress approach lets you configure fine-grained access by combining identity, request type, and network source conditions. Context-based ingress private access policies are also not region-bound: you can allowlist an endpoint in any region to serve a workspace in a different region. See Context-based ingress control. Private access settings are all-or-nothing, region-bound policies.

For traffic to be allowed, both the private access settings and context-based ingress must permit the endpoint. By default, context-based ingress is set to Allow access from all private endpoints, which defers the access decision to the workspace's private access setting. If you would like to configure context-based private access policies, make sure your workspace has a private access setting attached, with all registered private endpoints allowed (see more below). This will defer the access decision to your workspace's context-based ingress policy.

Preview

Private access to workspaces using context-based ingress is in Beta.

  1. In the account console, click Security in the sidebar.

  2. Click Context-based ingress & egress control in the sidebar.

  3. Under Workspace level policies, click New workspace policy.

  4. Under Ingress > Private Network Access, define your private access policy.

    1. By default, all registered endpoints are allowed: Allow access from all private endpoints. If this is acceptable, proceed to the next step. This default includes only the first 200 registered VPC endpoints; if your policy requires more, contact your account team for an increase.
    2. If you want to allowlist specific registered endpoints while denying all other endpoints, uncheck Allow access from all private endpoints and add an allow rule.
      1. Select the identities and workspace destinations you want to allow access to (by default all identities and destinations are allowed).
      2. Then select source type = Selected private endpoints, and select the General Access VPC endpoint(s) you registered. The region of this VPC endpoint does not have to match the region of your workspace. A General Access endpoint in any region can serve workspaces in any region.
      3. Click Confirm.
      4. You can also add Deny rules in your policy, which define exceptions to your allow rules.

  5. When you are done configuring your private access policy, you can also configure your public access policy in Ingress > Public Network Access. You can disable all public IP access by unchecking Allow access from all public IPs. Databricks recommends keeping public access enabled while testing your DNS configuration, then disabling it after DNS is finalized to enforce exclusive private connectivity.

  6. Test your ingress policy in Dry run mode first, before switching it to Enforced. Dry run mode access denials are logged in the system.access.inbound_network system table but will not block access.

  7. Make sure your Egress policy is correct.

  8. Attach your network policy to your workspace(s).

  9. Save your network policy. Context-based ingress policy updates take under 10 minutes to take effect.

  10. Attach an "allow all access" private access setting to your workspace. Workspaces with no private access settings attached have all private access denied, regardless of network policy.

    1. In the account console, click Security in the sidebar.
    2. Click Private access settings in the sidebar.
    3. Click Add private access settings.
    4. Enter a name for your new private access settings object.
    5. Select a region that matches your workspace region.
    6. Configure the Public access enabled field to True.
    7. Select a Private Access Level: Account.
    8. Click Add private access settings.
    9. Now in your workspace, click Advanced configurations to view additional fields.
    10. In the Private Link dropdown, choose the name of the private access settings object that you created in the previous steps.
    11. Click Save.
tip

You can create one network policy per workspace. However, if multiple workspaces share the same ingress and egress policies, they can share the same network policy, so you can "define once and attach anywhere".

tip

You can reuse the same "allow all access" private access setting across any workspace in the same region.

After creating and registering your inbound VPC endpoint, configure DNS to route user requests through your private network to the VPC endpoint's private IP address.

Every workspace has two valid URLs: your custom URL (for example, <my-custom-account-name>.databricks.com) and a workspace-specific URL (for example, dbc-<workspace-deployment-id>.cloud.databricks.com).

You must always route your workspace-specific URL to your workspace's VPC endpoint. If you want to use your custom URL for access, you must also route your custom URL to your workspace's VPC endpoint.

For comprehensive DNS configuration instructions, including Route 53 setup, conditional forwarding patterns, and troubleshooting guidance, see Configure DNS for AWS inbound Private Link.

Verify DNS resolution​

After configuring DNS, verify that both of your workspace URLs resolve to a private IP address, not a public IP address. These private IPs may differ from the IPs shown below.

Workspace-specific URL:

Bash
nslookup myworkspace.cloud.databricks.com

Expected output showing resolution through the privatelink subdomain. If you don't see privatelink in the canonical name, you didn't attach a private access setting to your workspace and private access will not work.

myworkspace.cloud.databricks.com    canonical name = sydney.privatelink.cloud.databricks.com
Name:    sydney.privatelink.cloud.databricks.com
Address: 10.176.10.182

Custom URL:

Bash
nslookup <my-custom-account-name>.databricks.com

Expected output:

<my-custom-account-name>.databricks.com
Address: 10.176.10.182

Workspaces with managed disaster recovery (see Managed disaster recovery) use your custom URL as their stable workspace URL, in the form <my-custom-url>.databricks.com/?c=stable_connection_id. This stable URL can serve both your primary and secondary workspaces.

To configure inbound Private Link for these workspaces:

  1. DNS resolve your custom URL to a registered General Access endpoint (see Configure DNS for AWS inbound Private Link).
  2. Using context-based ingress, allowlist this endpoint to both your primary and secondary workspaces.
  3. Create a failover General Access endpoint in another region, to be used if the primary region becomes unavailable. Databricks recommends, but doesn't require, creating it in the same region as your secondary workspace.
  4. Using context-based ingress, allowlist this failover endpoint to both primary and secondary workspaces.
  5. Repeat steps 3 and 4 in as many additional regions as you'd like.

How failover behaves:

  • Primary workspace down, primary endpoint still available: Your stable URL automatically continues to serve your secondary workspace through the primary endpoint. This works because a General Access endpoint in any region can serve workspaces in any region.
  • Entire primary region down: You must resolve your custom URL to another allowlisted General Access endpoint from steps 3–4. You can update your DNS records manually, or automate it using Route 53 health checks with failover records in a private hosted zone.

If your custom URL also serves workspaces without managed disaster recovery, make sure their context-based ingress policies also allow the failover endpoint(s), so access is preserved when the active endpoint changes.

Preview

Private access to account-level resources, including unified login, is in Beta. See Configure inbound Private Link for account-level resources.

If your users have access to the public internet (that is, DNS resolution can use public resolvers and authentication requests can use the public internet), this step is not required.

When a user logs in to a workspace where unified login is enabled, Databricks redirects them to accounts.cloud.databricks.com in the authentication flow. If users do not have access to the public internet, follow these steps to configure your identity provider and internal DNS.

  1. As an account admin, log in to the account console.
  2. In the sidebar, click Settings.
  3. Click the Authentication tab.
  4. Next to Authentication, click Manage.
  5. Choose Single sign-on with my identity provider.
  6. Click Continue.
  7. Copy the value in the Databricks Redirect URL field.
  8. Go to your identity provider.
  9. Add the Databricks Redirect URI as an additional redirect URL. If you configure SSO using SAML, also add the Databricks Redirect URI as an additional entity ID.

Set up a private hosted zone for your transit VPC​

Perform the following configuration in your transit VPC to verify that the Databricks Private Link Redirect URI maps to the VPC endpoint private IP address for your workspace VPC endpoint.

  1. Configure conditional forwarding in your corporate DNS to forward accounts.cloud.databricks.com to AWS.
  2. In your transit VPC, create a private hosted zone with the domain name accounts.cloud.databricks.com.
  3. Add an A record that resolves accounts.cloud.databricks.com to any General Access VPC endpoint private IP address that is registered in your account.
  4. Test the configuration by accessing the Databricks Private Link Redirect URI from your transit VPC.
note

If you are currently using accounts-pl-auth.privatelink.cloud.databricks.com as your redirect URL (legacy Private Preview option), your CBI account-policy will not take effect. First, allowlist the General Access endpoint currently used for unified login in your account-policy. Then, contact your account team to enable your account-policy. Finally, Databricks recommends changing your redirect URL to accounts.cloud.databricks.com. This process will prevent any of your existing account-level access from breaking.

Additional resources​

On this page