# Prerequisites

Gather these before you begin. The install will not succeed without them.

## Cloud accounts and compute

Use three isolated cloud environments, one per MPC shard:

| AWS | GCP |
|---|---|
| Three AWS accounts | Three GCP projects |
| EKS cluster in each account | Regional GKE cluster in a SEV-SNP region for a production deployment |
| Nitro-Enclave-capable Key Store nodes, such as `c5.xlarge` or `c7i.2xlarge` | N2D Confidential Key Store node pool using AMD SEV-SNP |
| AWS CLI profiles for all three accounts | Separate deployment credentials per party, Application Default Credentials, and `gke-gcloud-auth-plugin` |

The account or project boundary matters. A compromise of one environment should expose at most one
Key Store and one Policy Server, below the MPC threshold. You may place multiple shards in one account
or project for a test, but do not use that layout in production.

On GCP, each production party also owns a separate Terraform root, backend, and caller credential.
The combined three-cluster example uses one state and caller even when you provide three projects, so
use it only as an integration reference. Production requires regional Standard GKE, N2D with `SEV_SNP`, Secure Boot, integrity monitoring,
private control-plane access, enforced NetworkPolicies, and Cloud HSM. The binding constraint is
therefore **where AMD SEV-SNP is offered on N2D**, not a single named region. See
[Supported production regions](#supported-production-regions) below.

## Supported production regions

Production needs a region that offers **both** AMD SEV-SNP on N2D **and** Cloud HSM. Google offers
SEV-SNP on N2D in four regions:

| Region | SEV-SNP zones |
|---|---|
| `asia-southeast1` | a, b, c |
| `europe-west3` | a, b, c |
| `europe-west4` | a, b, c |
| `us-central1` | a, b, c |

Cloud HSM is available in all four, so any of them is a supported production region. Anywhere else is
a test or proof-of-concept deployment.

Release qualification is executed in `us-central1`. That describes where this deployment is exercised
end-to-end, not a restriction on where it may run.

:::warning\[N2D availability does not imply SEV-SNP availability]
`europe-west1` offers `n2d-standard-4` in all three of its zones and does **not** support SEV-SNP.
Checking that a region has N2D machine types is not a sufficient region check. Confirm against
[Confidential VM supported configurations](https://docs.cloud.google.com/confidential-computing/confidential-vm/docs/supported-configurations)
before choosing a region.
:::

Your chosen region must also have at least two SEV-SNP zones, because the Key Store runs Ready
replicas across more than one zone.

:::warning\[Different confidential-compute guarantees]
AWS runs the Key Store inside a measured Nitro Enclave and can gate KMS access on enclave attestation.
GCP runs the Key Store as a pod on a GKE Confidential Node. Confidential Nodes protect the node VM's
memory from the host and hypervisor, while Cloud KMS access is governed by Workload Identity rather
than per-workload attestation.
:::

## Databases

Provide one managed PostgreSQL instance per cloud environment: RDS for PostgreSQL on AWS or Cloud SQL
for PostgreSQL on GCP. The chart expects these logical databases:

| Database | Required on |
|---|---|
| `mpc_ks_db` | All three clusters |
| `policy_db_N` | All three clusters |
| `orchestrator_db` | Hub cluster only |

The example Terraform creates the instances, application identities, and databases. On GCP, every
database workload has its own Kubernetes and Google service-account pair and an in-pod Cloud SQL Auth
Proxy. The application connects to the sidecar over pod-local port 5432. If you bring your own
databases, create the databases and supply their connection settings, credentials, and workload
identities as Helm values.

## Encryption keys and workload identity

Provide one symmetric KMS key per shard for Key Store storage encryption:

* **AWS:** an AWS KMS key and IRSA role that grants the Key Store the required KMS operations.
* **GCP:** an HSM-backed Cloud KMS key in the deployment's region and a GCP service account bound to the Key
  Store Kubernetes service account through Workload Identity. Confirm Cloud HSM availability and
  quota before the first apply. The GCP Key Store image selected by the chart requires
  `roles/cloudkms.cryptoKeyEncrypterDecrypter` on the exact key and a project-scoped
  `roles/cloudkms.cryptoOperator` grant conditioned to the selected KMS location for
  `GenerateRandomBytes`.

The example Terraform creates and wires these resources. The GCP chart consumes the complete key
resource name through `gcp.kmsKey` and renders it as `[storage_encryptor.gcp_kms].kms_key`. Choose the KMS protection level before the first apply because
changing it later replaces the key and makes shares wrapped under the old key unrecoverable.
Automatic KMS rotation is intentionally disabled for this deployment.

## Credentials for the artifact registry

Obtain a JFrog access token from [repo.sodot.dev](https://repo.sodot.dev) using the **Set Me Up** panel
on the `sodot-terraform-modules` and `sodot-helm-charts` repositories. The same username and token
authenticate the Terraform module registry, Helm OCI registry, and in-cluster image pulls. The Sodot
team whitelists your email domain for access.

## MPC shard identities and backup keys

Each Key Store and Policy Server node self-generates its identity keypair on first boot. You do not
supply identity, signing, or verification keys. Provide:

* A name for each Key Store shard and reader/writer names for each Policy Server.
* One unique backup encryptor public key per Key Store shard (32 bytes, lowercase hex, 64 characters).

Key creation and import stay blocked until all three backup public keys are configured. Generate the
key pairs offline and keep the private keys outside the cloud environments. See
[Backup and disaster recovery](/deploy/operations/backup-dr).

## SSO and authentication

* A Google OAuth client ID and client secret for the hub UI.
* The Google Workspace email addresses of the Setup Admins.
* `https://<your-ui-host>/auth/callback` registered as an authorized redirect URI.

The client ID and Setup Admin emails must be present on every Policy Server cluster, while the client
secret is hub-only.

## DNS and TLS

Prepare distinct DNS hostnames for the vault UI and, if exposed externally, the Orchestrator API.

| AWS | GCP |
|---|---|
| ACM certificate ARN for each enabled front door | Google-managed certificate or your own TLS secret |
| Route53 hosted zone or your DNS provider | Cloud DNS managed zone or your DNS provider |
| Terraform-managed NLB | GKE Ingress with a reserved global IP |

Both front doors can be private to your VPN or zero-trust network. Key Store and Policy Server services
must remain private.

## CLI toolchain

| Tool | Minimum version or requirement |
|---|---|
| `kubectl` | 1.28 |
| `helm` | 3.12 |
| `terraform` | 1.14 |
| AWS | AWS CLI 2.x and credentials for all selected accounts |
| GCP | `gcloud`, Application Default Credentials, and `gke-gcloud-auth-plugin` |

## Multi-admin recommendation

If multiple people share the IT-admin role, plan to have at least two available during the verification
ceremony. The ceremony includes an out-of-band cross-check that is easier to perform with two people.

Continue with [Provision infrastructure](/deploy/provision-infra).