Azure

Sodot MPC Vertex is a self-hosted deployable service that represents an MPC party for MPC operations (such as keygen, sign, refresh etc.). It takes care of storing the secret share, as well as running the MPC operations themselves. It can be used seamlessly with all Sodot MPC SDKs. The Vertex exposes a REST API, documented here, that allows creating and managing secret shares easily.

Architecture

The self-hosted solution comes in two forms: a dedicated Terraform module and a Helm chart (which the Terraform module uses internally). 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 az CLI tool for Azure.
3. Make sure you are logged in (i.e az login).
4. 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 is made of the following steps:

1. Collecting installation parameters
2. Obtaining a TLS certificate
3. Obtaining the Terraform module
4. (Optional) Setting Up Azure Confidential Containers
5. Applying the Terraform module to your cloud environment
6. Setting the DNS Record for URL_ENDPOINT to point to the Vertex

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 Vertex at (URL_ENDPOINT).
2. The Sodot Docker registry user and token which provides access to all relevant Helm charts, Docker images and Terraform modules (ARTIFACTORY_USER and ARTIFACTORY_TOKEN). You can obtain these by following the Obtaining Credentials guide.

2. Obtaining a TLS Certificate

You should obtain a TLS cerificate for the URL_ENDPOINT domain. The certificate should be configured inside an instance of Azure Key Vault (KEY_VAULT_NAME). To use this certificate for the Vertex, make sure you pass the relevant variables when performing the terraform apply operation (more on that specifically below).

3. Obtaining the Terraform Module

You can consume the Vertex Terraform module from the Sodot private registry by downloading it as a zip file by its version.

1. Fetch the desired release (replace <VERSION> with a tag such as v1.10.1):

curl -u "<ARTIFACTORY_USER>:<ARTIFACTORY_TOKEN>" \
  -O "https://repo.sodot.dev/artifactory/sodot-terraform-modules/sodot/vertex/azure/<VERSION>.zip"

Alternatively, you can use the Artifactory GUI instead.

2. Unzip and make it your working directory:

unzip <VERSION>.zip -d vertex
cd vertex

4. (Optional) Setting Up Azure Confidential Containers

In order to run the Vertex on a CoCo (Confidential Container) node (on an AKS cluster) we have to:

1. Create a confidential amd sev-enabled Node Pool on our cluster.
2. Sign our Vertex helm chart with the templated values set by using the Azure cli extension confcom.

Unfortunately, at the moment Confidential Containers on amd sev are not supported in azurerm_kubernetes_cluster and azurerm_kubernetes_cluster_node_pool terraform resources. For this reason, until it will be fully supported and stable, we will call the az CLI from the terraform code therefore you will have to be logged in to the CLI before running terraform apply.

For MacOS users, the confcom extension is not supported so we are providing a Dockerfile that can be built and used to run the required terraform operations.

MacOS Builder Image

Inside the downloaded terraform code directory, build the builder image:

    cd coco_builder
    # build the image
    docker build . -t sodot-coco-terraform
    cd ..

Now run prepare the builder with all required credentials:

    # Create a docker volume to store your az credentials
    docker volume create azure_creds

    # Create a docker volume to store your artifactory credentials
    docker volume create docker_creds

    # First, login to az cli and store the creds
    docker run -v azure_creds:/root/.azure -v docker_creds:/root/.docker -it sodot-coco-terraform az login

    # Second, login to docker.io using Sodot Artifactory token - fill the token as the requested password
    docker run -v azure_creds:/root/.azure -v docker_creds:/root/.docker -it sodot-coco-terraform docker login repo.sodot.dev -u <ARTIFACTORY_USER> -p <ARTIFACTORY_TOKEN>

Finally, the terraform commands inside the builder image from the root directory of the repo:

    # Run these commands in the terraform code directory
    docker run -v azure_creds:/root/.azure -v docker_creds:/root/.docker -v .:/root/ -it sodot-coco-terraform terraform init

    docker run -v azure_creds:/root/.azure -v docker_creds:/root/.docker -v .:/root/ -it sodot-coco-terraform terraform apply

    # You can use the same command to perform other tf commands (e.g. destroy)

Enable the CoCo feature on your Azure Subscription

It is required to enable the Azure feature KataCcIsolationPreview on your account before running the terraform commands.

This can be done by running:

az feature register --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Verify that the feature is now enabled by running:

az feature show --namespace "Microsoft.ContainerService" --name "KataCcIsolationPreview"

Finally, refresh the registration of the Microsoft.ContainerService resource provider by using the az provider register command:

az provider register --namespace "Microsoft.ContainerService"

(Optional) Use Secure Key Release for the Vertex Storage Encryption

Secure Key Release Feature

Secure Key Release (SKR) is a functionality of Azure Key Vault (AKV) Managed HSM. Secure key release enables the release of an HSM protected key from AKV to an attested Trusted Execution Environment (TEE), such as the CoCo Deployment. SKR adds another layer of access protection to your data decryption/encryption keys where you can let only a specific application + TEE runtime environment with known configuration get access to the key material (in our case, only the Vertex will be able to access the DB encryption key). The SKR policies defined at the time of exportable key creation govern the access to these keys.

In order to use the SKR feature, you will need to spawn and activate a new Managed HSM instance, with you as the Managed HSM Administrator. After activating the Managed HSM, you will have to give yourself the Managed HSM Crypto Officer role (using the Local RBAC tab of the mHSM resource) in order to be able to create and manage keys.

5. Applying the Terraform Module to Your Cloud Environment

Setting up the relevant infrastructure is performed by running terraform init followed by terraform apply. Where you run those commands depends on the option you chose in Obtaining the Terraform Module.

Configuring Terraform

The module’s inputs are declared in variables.tf and have sensible defaults where appropriate. You must supply the following variables when invoking both terraform apply and terraform destroy:

• location - the location at which the cluster (and the rest of the resources) will be provisioned.
• artifactory_user=<ARTIFACTORY_USER> - provides Terraform with permissions to pull the Helm chart and the Vertex Docker image.
• artifactory_token=<ARTIFACTORY_TOKEN> - provides Terraform with permissions to pull the Helm chart and the Vertex Docker image.
• sodot_relay_api_key=<RELAY_API_KEY> - an API key for accessing the Sodot Relay Server.
• sodot_relay_url=<RELAY_URL> - the URL for your organization's deployed Relay Server.
• admin_access_token=<ADMIN_TOKEN> - the secret admin token that will be used to set up all other users of the Vertex.
• tls_cert_key_vault_name=<KEY_VAULT_NAME> - configure the name of the key vault holding the certificate.
• tls_cert_rg_name=<KEY_VAULT_RESOURCE_GROUP> - configure which Resource Group the key vault is associated with.
  • NOTE: This is not the Resource Group that the Vertex cluster will be created under.
• tls_cert_uri=<CERTIFICATE_ID> - the ID (URI) of the certificate that will be used for TLS termination.
• vertex_dns_address=<URL_ENDPOINT> - equal to URL_ENDPOINT.

The rest of the variables have sensible defaults, but it is recommended to go over them and customize them for your own needs.

• coco_enabled=<boolean> - set to true if you wish to run the Vertex as an Azure Confidential Container (requires following the above step).
• confidential_node_vm_size=<node pool VM size> - defaults to Standard_DC4as_cc_v5, determines the node pool VM size.

(Optional) SKR Configuration

• secure_key_release_encryption_hsm_name=<HSM_NAME> - the name of the Managed HSM instance that will be used for SKR (see above requirements).
• secure_key_release_encryption_hsm_rg_name=<HSM_RESOURCE_GROUP> - the name of the Resource Group that the Managed HSM instance is associated with.

Backup Settings

If you wish to backup your key shares manually, consult the Backing Up Key Shares guide for more Terraform configurations and info.

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.

Example for option B (inside the unzipped directory):

terraform init

terraform apply \
    -var "location=westus" \
    -var "tls_cert_uri=https://keyvault-xx.vault.azure.net/secrets/cert-xx/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" \
    -var "tls_cert_key_vault_name=keyvault-xx" \
    -var "tls_cert_rg_name=DefaultResourceGroup-XXX" \
    -var "artifactory_user=my-artifactory-user" \
    -var "artifactory_token=my-artifactory-token" \
    -var "sodot_relay_api_key=ABEiM0RVZneImaq7zN3u8g==" \
    -var "sodot_relay_url=my-relay.XXXXX.com" \
    -var "admin_access_token=XXXXXXXXXXXXXXXXXX" \
    -var "vertex_dns_address=my-vertex.XXXXX.com" \
    -var "coco_enabled=true" \
    -var "confidential_node_vm_size=Standard_DC4as_cc_v5"

6. Setting the DNS Record for URL_ENDPOINT to Point to the Vertex

After running terraform apply there will be a command that is output of the format:

az aks get-credentials --resource-group "<DATA_HERE>" --name "<MORE_DATA_HERE>"

Run this command and then run:

kubectl get ingress

To get the IP address for your Vertex. Then 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 Vertex.

Now, you can run:

curl https://URL_ENDPOINT/health -vvv

To verify that you get an empty 200 OK response from the Vertex and that it is indeed up and running.