CloudBridge
Reference
As a Platform Administrator, you use CloudBridge so Acceldata's Control Plane can reach your Dataplane without you opening inbound access on your network. The Dataplane starts an outbound, mutually authenticated TLS session; every later Control Plane action rides that same pipe.
CloudBridge is used only for Control Plane → Dataplane traffic. It is not the path the Dataplane uses to call back to the Control Plane.
How CloudBridge protects the channel
Your Dataplane never publishes an inbound hole to Acceldata. It opens outbound HTTPS (TCP 443) to the production CloudBridge hostname and keeps that session alive. Mutual TLS (mTLS) proves both sides before the session is accepted: CloudBridge presents a server certificate, and your Dataplane presents an Acceldata-signed client certificate and key issued for that Dataplane.
When you take an action in xDP (submit a Spark job, run a Trino query, change a governance policy), the Control Plane does not open a new connection into your network. CloudBridge multiplexes a short-lived encrypted channel over the existing pipe, delivers the request to the Dataplane, returns the response on the same channel, then tears that channel down. The persistent mTLS pipe stays up.
Layer | What it proves | When it applies |
|---|---|---|
Persistent pipe | Server identity + client certificate, before any request is forwarded | From Dataplane start until disconnect or revoke |
Per-request channel | Encrypted delivery of one Control Plane action and its response | Created and destroyed for each action |
Certificate revoke | Instantly invalidates that Dataplane's client certificate | When you decommission or rotate a Dataplane |
Note: CloudBridge verifies the client certificate before the session is accepted, so an unknown client never gets a pipe.
How the working path looks
The Dataplane sits behind your egress-only firewall. CloudBridge is the only Acceldata surface it dials. The Control Plane never targets your cluster address.
Each action follows the same four steps. The persistent pipe is established once; steps 2–4 repeat for every UI action.
Production endpoints
Whitelist this hostname for outbound TCP 443 from every production xDP Dataplane.
Environment | CloudBridge — whitelist | Port | Direction |
|---|---|---|---|
Production |
| 443 | Egress from the Dataplane |
If the Dataplane uses an HTTPS proxy, the proxy must allow the same CloudBridge hostname and port.
Configuration options
Parameter | Description | Production value | Required |
|---|---|---|---|
CloudBridge hostname | Outbound endpoint the Dataplane dials |
| Yes |
Port | TLS port for the persistent pipe |
| Yes |
Direction | Allowed firewall direction | Outbound from the Dataplane only | Yes |
Client certificate | Acceldata-signed identity for this Dataplane | Issued when the Dataplane is created or rotated | Yes |
HTTPS proxy | Optional corporate proxy in front of egress | Your proxy host:port, if required | No |
Verify production reachability
From a workload already running in the Dataplane namespace, an HTTPS connect to cloudbridge-xdp.acceldata.app on port 443 must succeed (direct or via your proxy). A successful check shows an opened stream to that hostname. If it does not, the hostname is not reachable — confirm the firewall or proxy allow-list.
Tip: Whitelist
cloudbridge-xdp.acceldata.appfirst, then confirm outbound 443.