Skip to main content

GCP

The Relay Server is the plumbing that all MPC communication goes through. It is built in a way that it is completely untrusted and so the MPC SDKs and MPC Vertex will encrypt all data before sending it through the Relay. To deploy the Relay server on your cloud environment please read the guide below.

Architecture​

The self-hosted solution comes in two forms: a dedicated Terraform module per cloud provider, and a general use Helm chart. Both should be run on your organization's computing infrastructure. We recommend you first look at our example Terraform module and modify it according to your organization's needs.

Requirements​

Before starting the installation process, make sure you have the following installed:

  1. The terraform CLI.
  2. The gcloud CLI tool for GCP. Make sure the following are true:
    1. You are logged in (i.e gcloud auth application-default login - notice this is different from gcloud auth login).
    2. Your account has permissions to create resources (such as GKE clusters, load balancers, key rings, etc...).
    3. You enabled the relevant APIs in your GCP project (e.g. "Cloud Key Management Service (KMS) API", "Kubernetes Engine API", etc...).

In addition, this guide assumes you're running the provided example Terraform module as the root module (although most steps are applicable when running it as a submodule as well).

Installation Process​

The installation process consists of the following steps:

  1. Collecting installation parameters
  2. Cloning the Terraform Module
  3. Obtaining a TLS certificate
  4. Setting a preconfigured API key
  5. Applying the Terraform module
  6. Setting the DNS record to URL_ENDPOINT
  7. Modify existing code

1. Collecting Parameters​

At this step you should collect the following pieces of information, listed down below. At the end of each bullet we put in parentheses a capitalized name which will be used to refer to the value being set throughout the rest of this guide.

  1. The endpoint URL that you wish to host your relay server at (URL_ENDPOINT).
  2. The GitHub token which provides access to the Terraform module (GH_TOKEN).
  3. The DockerHub token which provides access to all relevant Helm charts and Docker images (DOCKERHUB_TOKEN).

2. Cloning the Terraform Module​

Before starting the actual setup process, you will need to clone the Terraform module from the Sodot repository. At this point, you should have a GitHub token that provides access to the Terraform module (GH_TOKEN).

git clone https://x-access-token:<GH_TOKEN>@github.com/sodot-rs/sodot-relay-gcp-terraform.git

3. Obtaining a TLS Certificate​

You should obtain a TLS certificate for the URL_ENDPOINT domain via GCP Certificate Manager, using Classic Certificates. The certificate can either be requested or imported from an existing certificate. We will need the unique name of your certificate (TLS_CERT_NAME).

4. Setting a Preconfigured API Key​

When setting up your relay server, you should configure an API key. This is done by passing the relay_api_key variable to the terraform apply invocation (more on that below).

The relay_api_key value is encoded as KEY,NAME where KEY is the base16 encoding of a 16-byte value and NAME is the name of the API key.

Example

To set a 16-byte API key with the following hexadecimal representation: 00112233445566778899aabbccddeeff with the name AdminKey pass relay_api_key=ABEiM0RVZneImaq7zN3u/w==,AdminKey when invoking terraform apply.

tip

A hexadecimal string can be base64-encoded in bash-like shells using the following command.

$ echo -n '00112233445566778899aabbccddeeff' | xxd -r -p | base64
ABEiM0RVZneImaq7zN3u/w==

5. Applying the Terraform Module to Your Cloud Environment​

Setting up the relevant infrastructure is performed by running terraform apply (after terraform init). This will provision a GKE cluster with an Application Load Balancer, and will connect the load balancer with access to the certificate provided (for TLS termination).

Configuring Terraform​

The variables for the terraform module are located in variables.tf and are provided with sensible defaults where applicable. Users are required to pass the following variables when calling terraform apply (and terraform destroy respectively):

  • location - the location of your GCP project.
  • project_id - the project ID of your GCP project.
  • dockerhub_token=<DOCKERHUB_TOKEN> - allows Terraform to install the relevant Helm chart and access the Relay image.
  • relay_api_key=<RELAY_API_KEY> - described above.
  • ssl_certificate_name - the name of the certificate TLS_CERT_NAME as described in Obtaining TLS Certificate.
  • relay_dns_address=<URL_ENDPOINT> - described above.

An example command will look like this:

terraform apply \
    -var "location=us-central1" \
    -var "project_id=my-project" \
    -var "ssl_certificate_name=my-tls-cert" \
    -var "dockerhub_token=dckr_pat_xxxxxxxxxxxx" \
    -var "relay_dns_address=my-relay.XXX.com" \
    -var "relay_api_key=ABEiM0RVZneImaq7zN3u8g==,AdminKey"

6. Setting the DNS Record for URL_ENDPOINT to Point to the Relay Server​

After running terraform apply successfully, the resulting external IP address to the internal load-balancer will be outputted under the name ingress_ip.

After getting the external IP address of your Relay Server, you will need to create an A record for URL_ENDPOINT that points to that address (you can also use an A-alias record to point directly at the load balancer object). Then, at https://URL_ENDPOINT you will be able to communicate with your Relay server.

To verify, you can run:

curl -H "Authorization: Bearer <RELAY_API_KEY>" https://URL_ENDPOINT/create_room/2

Which should yield a new room ID string if a Relay Server is configured behind the address correctly.

7. Modify Existing Code​

By default, the Ecdsa,Ed25519,StatefulEcdsa and StatefulEd25519 classes are routed to a Sodot owned Relay Server. This can be changed by supplying an additional parameter specifying the URL of the on-prem Relay Server.

For instance, consider the const ecdsa = new Ecdsa() constructor call. Calling it should now be made with the extra parameter of URL_ENDPOINT like so:

const ecdsa = new Ecdsa(URL_ENDPOINT);

The same holds for the calling to any of the following constructors as well:

const ed25519 = new Ed25519(URL_ENDPOINT);
const ecdsa = new StatefulEcdsa(URL_ENDPOINT);
const ed25519 = new StatefulEd25519(URL_ENDPOINT);

More information can be reviewed in the API references for each of the different classes.