Add a JFrog Bridge

Follow the procedure described here to define a new JFrog Bridge.

Prerequisites

Firewall Whitelisting: Whitelist outbound traffic via port 443 to the SaaS site URL so the Bridge Client service can send requests to the Bridge Server.
Circle of Trust: Some federation services use a Circle of Trust to secure data sync. Configure the Circle of Trust between JPDs before you define the Bridges that support the service. If you defined the Bridges first, restart the Bridge connections after you configure the Circle of Trust.

To add a new Bridge connection:

Enable the JFrog Bridge service: On the Self-managed JPD that is the Client of the new Bridge, modify the values.yaml file and set the bridge:enabled: parameter to true.

Don't Define Bridges in YAML. Bridges you define directly in system.yaml appear in the Bridges table, but cannot be managed using the Platform interface or the Bridge APIs. Use this procedure or the Bridge APIs to create Bridges.
Log in to the Self-managed JPD that is the Bridge Client.

In the Administration module, go to Monitoring > Service Status and verify that the Bridge Client service is active. If necessary, install the Bridge Client service on the JPD.
Log in to the (SaaS) JPD that is the Server of the new Bridge. In the Administration module, go to Topology > Bridges > Bridge Server.

The JPD is the Server for the Bridges in this table.
Click Generate Pairing Token. In the Generate Pairing Token dialog, click Generate.

Click Copy to copy the Token string. Save this string.
Log in to the (self-managed) JPD that is the Client of the new Bridge. In the Administration module, go to Topology > Bridges > Bridge Client.

The JPD is the Client for the Bridges in this table.
Click New Bridge.

The New Bridge Connection dialog opens. The following table describes the configuration parameters of the dialog.

Parameter	Description
Bridge ID	A unique identifier for the Bridge. This string can contain only lowercase letters, numbers, and hyphens (-). Do not use the string `server` or `client`. Do not reuse an existing Bridge ID.
Bridge Client URL	The URL of the JPD that is the Client of the Bridge. The Server routes Bridge data to this address.
Bridge Server URL	The URL of the JPD that is the Server of the Bridge. This address is used to establish Bridge connections.
Pairing Token	A single-use token that authenticates new Bridge creation. Use the token you generated on the Bridge Server JPD in Step 3.

Click Create Bridge. The new Bridge appears in the table.
Log in to the (SaaS) JPD that is the Server of the new Bridge. Register the Bridge Client JPD as described in Register a Platform Deployment. Enter the following string for the URL value:
```
http://localhost:8046/bridge-<Bridge_ID>
```
where <Bridge_ID> is the Bridge ID of the new Bridge.
Go to Administration > Topology > Bridge. Find the new Bridge in the table. Click ... in the Actions column and select Test Connection to confirm Bridge operation. Click anywhere in the row to view details for all nodes of the Bridge. If necessary, troublehoot Bridge communication. Most initial connection failures stem from outbound firewall permissions issues on the Self-managed site.

Repeat this procedure to define all the Bridges required for the service.

Add Bridged Sites to Multi-site Services

Circle of Trust: Some federation services use a Circle of Trust to secure data sync. If you defined the Bridges before the Circle of Trust, restart them as follows:

Log in to the JPD that is the Bridge Client and go to Administration > Topology > Bridges.
In the Bridge Client tab, find the Bridge and click its ... icon in the Actions column. Select Restart.
Repeat these steps for all Bridges that support the service.

Service-Specific Configuration Steps: in some multi-site services, you add Bridged sites as any other site in your subscription. For example:

For an Access Federation , add the Bridged site to the federation like any SaaS site.
For Distribution, add the Bridged site to your Distribution configuration like any Edge node.

Other services require additional configuration steps before you add the Bridged site. For example:

For a Federated Repository, apply additional configuration steps to include a Bridged site.
For a Curation Federation, apply additional configuration steps to include a Bridged site.
For a Smart Remote Repository, not all authentication methods are supported when you define a Smart Remote Repository with a JFrog Bridge.

Use a Custom TLS Certificate for Bridge Communication

By default, communication between Bridge Client and Server is authenticated by a TLS certificate provided by the JPD's Access service. When the Self-managed site uses a self-signed certificate, or a certificate not signed by the JFrog Access service, you must define a custom certificate for Bridge communication. If you did not install a custom certificate during Bridge Client installation, use the methods described here to define a custom certificate.

There are several ways to upload a certificate dedicated to Bridge communication:

Add a certificate for a specific Bridge. When this certificate is defined, all nodes of this Bridge use only this certificate.
1. Generate the certificate in PEM format. Include a key to the CA used to sign the certificate.
2. Log in to the Bridge Client JPD and go to Administration > Topology > Bridges.
3. Click ... in the Actions column of the Bridge and select Edit.
4. In the Edit Bridge pane, paste the certificate into the TLS Root CA Certificate field. Then Click Update Bridge.
Add a certificate for all Bridges on the JPD. When this certificate is defined, Bridge services use this certificate instead of the JPD's default TLS certificate.
1. Generate a certificate file named tls_cert.crt in PEM format. Include a key to the CA used to sign the certificate.
2. Upload the file:
  
  For Docker or Linux deployments, save the file to the following pathname: $JF_PRODUCT_HOME/var/data/bridge/tls_cert.crt
  
  For Kubernetes deployments, create a secret that points to the certificate file, and specify the secret in the tunnelClientCertificateSecretName: field of the values.yaml file.