Firewall

Allow/deny rules between sources and destinations.

The internal firewall is an ordered set of allow / deny rules that the runtime evaluates at the start of every transport run. It governs which side of the system — the cloud server or a specific on-prem client — is permitted to run a given transport, giving you a central guard rail on top of the per-connection placement.

The firewall is optional and off by default: when it is disabled, every run proceeds as before.

Enabling the firewall

Turn it on under Settings → Runtime (the Firewall section). Once enabled, a Firewall entry appears in the sidebar — immediately after you save, with no page reload. The page and the feature are Admin-only.

Rules

Each rule has:

• Priority — rules are evaluated in order; the first matching rule decides the outcome.
• Source and Destination — each is one of Cloud, All Clients, or a specific client. The destination can also be Serving (Lakeflow / Spark) — a virtual target for the live-serving relay (see below).
• Action — Allow or Deny.
• Enabled — a rule can be switched off without deleting it.
• Description — free text to explain the intent.

At run start the runtime finds the highest-priority matching rule for the run's source/destination pair and allows or blocks the run accordingly. A few built-in baseline rules ship with sensible defaults; they are marked as built-in and can be disabled but are kept as the safety net.

Serving destination

A rule whose destination is Serving governs the live-serving relay — a client reading its on-prem source and streaming it live to the cloud for an external consumer (Databricks Lakeflow, or Spark via the PySpark connector) to pull. It is the most sensitive egress channel, so you can forbid it independently of normal cloud egress: {a client} → Serving : Deny stops that client from serving live, even if it may still push to normal cloud sinks. Unlike the classic rules, serving defaults to allowed — it is only blocked by an explicit deny — so turning the firewall on never silently breaks existing serving.

Typical uses

• Restrict a sensitive transport so it may only run via a specific client (and never cloud-direct).
• Block all clients from a destination that should only be reached from the cloud, or vice-versa.

See also Connections (per-connection placement) and Transports.