Skip to main content

Azure

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 relevant cloud provider CLI (e.g. az for Azure).
    1. Make sure you are logged in (i.e az login).
    2. Make sure your account has permissions to create resources (such as clusters, load balancers, 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-az-terraform.git

3. Obtaining a TLS Certificate

You should obtain a TLS certificate for the URL_ENDPOINT domain. It should be generated for the exact URL_ENDPOINT. Where and how that certificate will be passed to the relay server depends on your cloud provider:

Azure

The certificate should be configured inside an instance of Azure Key Vault (KEY_VAULT_NAME). To use this certificate for the relay server, please pass the following variables when performing the terraform apply operation (more on that specifically below):

  • resource_group_location=<LOCATION> - the location at which the cluster will be provisioned. Not to be confused with key_vault_resource_group.
  • key_vault_name=<KEY_VAULT_NAME> - configure the name of the key vault holding the certificate.
  • key_vault_resource_group=<KEY_VAULT_RESOURCE_GROUP> - configure which Resource Group the key vault is associated with.
    • NOTE: This is not the Resource Group that the Relay cluster will be created under.
  • certificate_id=<CERTIFICATE_ID> - the ID (URI) of the certificate that will be used for TLS termination.

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 an AKS cluster with an Azure WebAppRouting Controller, and will connect the controller with access to the designated key vault (in order to use 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):

  • 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.
  • relay_dns_address=<URL_ENDPOINT> - described above.
  • resource_group_location=<LOCATION> - described above.
  • key_vault_name=<KEY_VAULT_NAME> - described above.
  • key_vault_resource_group=<KEY_VAULT_RESOURCE_GROUP> - described above.
  • certificate_id=<CERTIFICATE_ID> - described above.

In addition, for Azure, the Terraform module will attempt to create a new Resource Group for all of its resources. To change this behavior, you can modify the following optional variable:

  • existing_resource_group_name - will reuse the specified existing Resource Group instead of creating a new one when provisioning resources.

An example command will look like this:

terraform apply \
-var "resource_group_location=westus" \
-var "certificate_id=https://keyvault-xx.vault.azure.net/secrets/cert-xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
-var "key_vault_name=keyvault-xx" \
-var "key_vault_resource_group=DefaultResourceGroup-XXX" \
-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 raw IP address will be output under the name load_balancer_ip.

After getting the IP address of your Relay Server, you will need to create an A record for URL_ENDPOINT that points to that IP. 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.