Skip to main content

What You Will Build

This deployment provisions a complete, horizontally-scalable MPC network on Google Cloud. The infrastructure spans two projects with a deliberate trust boundary between them:

  • Workload project — runs all compute and data: operators, WPBE, the database, and monitoring.
  • Secret Guardian project — holds the cryptographic root of trust (KMS keys and operator configuration secrets), released to operators only after hardware attestation.

Core resources

Network foundation

  • A custom VPC with a single private subnet — no VM has a public IP.

Database

  • A managed Cloud SQL for PostgreSQL instance with automated backups.

Operators

  • Each operator runs as a Confidential Space (TEE) workload.
  • Each operator is a Managed Instance Group (MIG) with replicas_per_operator VMs, fronted by an internal TCP load balancer so the load is distributed evenly across the replicas. Auto-healing replaces unhealthy replicas.
  • Each operator is isolated from others by own service account and its own secrets.

Secret Guardian — attestation-gated key custody

  • A separate project holding per-operator KMS keys and operator configuration secrets.
  • An operator can decrypt its keys only while presenting a valid GCP Confidential Space attestation.

Monitoring

  • A Jaeger VM collecting OTLP traces from operators and WPBE, reachable over the private subnet and via IAP for the UI.

Architecture

Fully detailed architecture diagram. Repeats the concepts from Introduction, but includes Google Cloud specific resources into a picture.

Loading Diagram...

Trust flow in one sentence: a client reaches the network only through the public WPBE; WPBE forwards MPC work to the operators'; each operator runs inside a TEE, talks to its peers over the private network, mutually attestates, persists state to the private Cloud SQL instance, and unlocks its cryptographic keys from the Secret Guardian project only by proving its attestation.

Setup Terraform

Terraform allows to automate deployment, instead of manually execute command from the CLI of given cloud provider, Terraform scripts describe what resource needs to be created and in what order. Terraform keeps a state of created resources, so it's very easy to change any of it. In this tutorial we are going to use open source for of Terraform called OpenTofu.

Clone the scripts used further for the deployment

git clone https://github.com/silence-laboratories/silent-network-deploy.git

How does it work

Using OpenTofu you will create the Silent Network deployment. The deployment consist of:

  • Postgres database - for storing data produced by the MPC Nodes
  • Jaeger services, Open Telemetry Collector - for monitoring
  • WPBE (optional) - backend service that connects to the MPC Nodes
  • Operators, aka MPC Nodes (up to 5)
  • And all Google specific resources, like service accounts, disks that are required for the services to start.

All services will be deployed in the same Google project (except for Secret Guardian), same region. VMs have ephemeral IPs. They communicate using internal DNS. So restart of any VM will not break the communication.

If you need to assign static IP to any service (for example to the WPBE that will serve externally), do this manually.

OpenTofu tracks the deployment in a state files, by default stored on your machine. This deployment will store them in Google Buckets. Thanks to the remote storage, you can work with your deployment from any machine you like - contrary to the default local storage.

TF directory

The TF directory holds several child dirs:

  • network_bootstrap - Creates disks, service accounts and other Google Cloud specific resources that needs to be created just once
  • network_common - spawns the PG Database, Jaeger, and other services that are used by Network. For simplicity and the cost reduction, the PG is hosted as VM. There is dedicated data disk created, and attached to the PG VM, so It's safe to destroy the VM, the data will persist on the dedicated disk.
  • wpbe{_bootstrap} - handles deployment of WPBE
  • operator{_bootstrap} - handles deployment of all N Operators
  • secret_guardian{_bootstrap} - creates sensitive resources on separate project

For each directory, separate state-file is created. The modules with bootstrap in name are meant to be applied just once over the lifetime of the deployment. The modules without that suffix hold often changing resources, like VMs. Reason for each Network component to have own separate directory and state file, is to easy share the WPBE deployment to backend developers, Operator deployment to external Operators, etc.

The terraform states are stored, encrypted and versioned on google bucket.

The state is stored in a form: bucket/{prefix}-{tf-module}.

  • Where prefix is used to separate deployments in the same project. So Alice can have own deployment, not interfering with Bob's deployment.
  • The tf-module is the name of the child directory.

The states are:

  • Encrypted, because terraform stores sensitive data, like value of env vars
  • Versioned, so it is possible to rollback to previous version of the deployment.

Prerequisites

Install OpenTofu

Install it by following the official instructions

Verify:

tofu -version

The deployment was tested on

OpenTofu v1.9.1
on linux_amd64

Install gcloud CLI

Follow official instructions

Configure Application Default Credentials (ADC):

gcloud auth application-default login

This will create a credentials file in ~/.config/gcloud/application_default_credentials.json, which are used by tofu to access Google Cloud. Keep it safe.