Federation Proxy

Federation Proxy is a platform capability that enables Federated Connectors to reach source systems that would otherwise be inaccessible from Databricks Serverless compute — including databases on private corporate networks, on-premises infrastructure, and cloud sources with strict IP allowlisting.

The proxy acts as a secure, Harbr-managed intermediary. Rather than Databricks Serverless compute attempting to connect directly to the source system — which fails when the source is on a restricted network — traffic is routed through a proxy that exposes a fixed, known set of IP addresses. Data owners allowlist only these proxy IP addresses, rather than the entire Databricks Serverless IP range.

Why this matters

Databricks Serverless compute runs in Databricks's own cloud environment, outside the client's virtual network. This means that when source systems sit on a private or on-premises network, Serverless compute has no path to reach them. This blocks federated access for consumption journeys that require Serverless — including Delta Shares.

The Federation Proxy solves this by sitting within the platform and routing Serverless compute traffic to the source system through a single, stable set of IP addresses. The source system owner grants access to the proxy IPs only — a significantly narrower allowlist than what Databricks Serverless would otherwise require.

How it works

When a Federated Connector is first created, the platform checks whether the Federation Proxy feature is enabled for the environment and whether the connector type is in scope. If so, the connector is automatically assigned a proxy address — a Harbr-managed DNS name and port.

This process is fully automated. There is no additional configuration required on the connector form. Once the operator has completed the one-time proxy registration and enabled the feature flag, all new federated connectors benefit from proxy routing automatically.

What is and is not affected

• Federation Proxy applies to database connectors used for federated (at-source) assets — for example, Microsoft SQL Server or MySQL.

• Once a connector is routed through the proxy, federated assets created from it can be consumed via Delta Share, Export, and Spaces in the same way as any other federated asset.

• The proxy is transparent to producers and consumers. Asset creation, subscription, and consumption workflows are unchanged.

• Data is never stored or copied by the proxy — it is a connectivity bridge only. All queries are still executed against the source system in real time.

Network requirements

For the Federation Proxy to function, the source database must be reachable from the proxy's network location. This means:

• The data owner must allowlist the proxy's IP addresses on their source system's firewall or network access controls. Your Harbr operator will provide the specific IP addresses for your environment.

• For on-premises databases, additional network configuration (such as routing rules or firewall exceptions) may be needed to allow inbound traffic from the proxy's cloud-hosted location to the private network.

Limitations

• Federation Proxy is currently available on Azure-hosted Databricks data planes only.

• The proxy admin API (/manage/connector-proxies/*) has no UI in the 5.30 Harbr version and is operated by your platform admin or Harbr support team.

• Proxy registration and lifecycle management (registering, draining, deleting proxies) is an operator-level action — end users do not interact with the proxy directly.

• Each proxy environment supports a finite number of concurrent source connections. Contact your Harbr Account Manager if you expect a large number of federated connectors.