Bridges¶
What is a Bridge?¶
A Bridge is a lightweight agent that you deploy within your own network to connect your on-premises environment to the Zaita SaaS control plane. It is the mechanism through which the platform performs certificate operations — including discovery, provisioning, and deployment — inside network boundaries that are not reachable from the internet.
The Zaita control plane never initiates inbound connections into your environment. All communication originates from the Bridge, which polls outbound to the SaaS. This means no firewall ingress rules are required. Your internal network remains closed; only outbound HTTPS traffic from the Bridge to the platform is needed.
Primary Functions¶
A Bridge serves two distinct functions within the platform architecture.
1. Job Execution¶
The Bridge continuously polls the SaaS control plane for pending jobs. When a job is available, the Bridge retrieves an encrypted payload containing the job definition and any associated data — including target system credentials where required. The payload is encrypted by the back control plane using that Bridge's current public key before it is made available for retrieval.
The Bridge decrypts the payload in memory and executes the job. Decrypted data is never written to disk. Once execution is complete, the Bridge reports the outcome back to the SaaS control plane.
Jobs assigned to a Bridge include:
- Certificate deployment — installing certificates onto target systems within your network.
- Key pair generation — generating cryptographic key pairs on local hardware.
- CSR creation — generating certificate signing requests for submission to the platform.
- Certificate discovery — scanning internal systems and reporting discovered certificates to the inventory.
2. Courier TLS Proxy¶
The Bridge acts as a TLS proxy for Couriers operating within your network. Rather than requiring each Courier to have direct outbound access to the internet and the SaaS control plane, Couriers can be configured to communicate exclusively with a local Bridge. The Bridge forwards those requests to the SaaS on the Courier's behalf.
This enables tighter network segmentation — Couriers are restricted to LAN access only, with the Bridge serving as the single controlled egress point for all platform communication.
Job Payload Encryption¶
The Bridge maintains an asymmetric key pair whose public key is registered with the SaaS control plane.
When a job is dispatched to a Bridge, the back control plane encrypts the entire job payload — including any target system credentials — using that Bridge's registered public key before the job is made available. The Bridge retrieves the encrypted payload, decrypts it in memory using its private key, and proceeds with execution. At no point is the decrypted payload persisted to disk or accessible to the SaaS control plane.
This model ensures that sensitive data such as target system credentials is protected end-to-end: encrypted at rest in the platform, in transit, and only briefly decrypted in memory within your network boundary at the point of use.
Trust Relationship¶
When a Bridge is first deployed, it establishes a trust relationship with the SaaS control plane using an initial one-time registration token. The token is generated when the Bridge is created in the portal and is consumed during the first registration call. Once used, the token cannot be reused.
After registration, ongoing trust is maintained through cryptographic heartbeats: the Bridge signs the current Unix timestamp with its private key, and the control plane verifies the signature against the registered public key. This ensures every heartbeat is authenticated without requiring persistent sessions or shared secrets.
If a Bridge instance stops communicating or is suspected of compromise, delete the instance from the portal — the next heartbeat attempt from that instance will fail immediately.
For high-availability deployments running multiple instances, each instance holds its own independent key pair and registration token. See Best Practices for details.
TLS Certificate Management¶
The Bridge listens on port 443 to serve as a TLS proxy for Couriers. It automatically obtains a TLS certificate from the Zaita platform during initial registration and manages all subsequent renewals itself. This is a fully automated process — no manual certificate configuration or intervention is required. The Bridge's certificate is issued by the platform and rotated before expiry without any disruption to Courier connectivity.
Self-Updating Architecture¶
The Bridge is a Rust binary that operates as a daemon, Windows service, or Docker container within your environment. It is a full monolithic binary — all capabilities are built in.
When installed as a Linux SystemD service or Windows service, the Bridge can update itself on request initiated from the SaaS web portal. Docker deployments require a manual image pull and container restart to apply updates. When an update is available, the platform raises an alert in the web portal.
Deployment Options¶
The platform supports two deployment method classifications:
| Method | Description |
|---|---|
| Standalone Binary | Run directly on any supported host. Available as a Windows installer (.exe) that registers as a Windows service, a Linux package (.deb / .rpm) that registers as a SystemD service, or a bare binary for environments where a system installation is not required. |
| Docker Container | Deploy within a Docker environment. Requires a persistent volume to retain trust tokens and key material across container restarts. |
For deployment instructions, see Setting Up a Bridge.
Network Requirements¶
The Bridge requires outbound HTTPS access (port 443) to the Zaita SaaS control plane for its region. No inbound firewall rules are required. The Bridge must also have network access to any target systems it is expected to reach for certificate deployment or discovery.
| Direction | Protocol | Destination | Purpose |
|---|---|---|---|
| Outbound | HTTPS (443) | Zaita SaaS (regional endpoint) | Heartbeat, job polling, key registration |
| Outbound | WinRM (5985/5986) | Windows target systems | Certificate deployment |
| Outbound | SSH (22) | Linux target systems | Certificate deployment |
| Inbound | HTTPS (443) | Couriers (internal network) | Courier TLS proxy |