Skip to main content

Set up backend resources

This step creates everything the services run on top of: the VPC and its firewall rules, the operator service account, the keyshare storage bucket, the private Cloud SQL instance, and the Secret Manager secrets for the backend services.

Log in to gcloud with credentials that have access to the backend project.

Enable Google Cloud APIs

gcloud services enable \
  confidentialcomputing.googleapis.com \
  compute.googleapis.com \
  iam.googleapis.com \
  secretmanager.googleapis.com \
  servicenetworking.googleapis.com \
  sqladmin.googleapis.com \
  --project=BACKEND_PROJECT_ID

Apply

tofu -chdir=deploy/gcp/tf/bootstrap-backend init
tofu -chdir=deploy/gcp/tf/bootstrap-backend apply -var-file=../global.tfvars

The Cloud SQL instance has no public IP and is reachable only from inside the VPC. Creating it takes several minutes.

Generate secrets

The script generates the database passwords, the Django SECRET_KEY for auth-svc, and the Ed25519 signing key for duo-server, then stores them in Secret Manager.

The script expects the following binaries to be installed:

  • gcloud
  • openssl with Ed25519 support
  • tofu
  • jq
./deploy/gcp/scripts/generate-secrets-backend.sh

The script also prints the public verifying key that the mobile app needs:

duo-server verifying key: 01<64 hex characters>

Save the full value after the colon, including the 01 prefix, for Test with the mobile app. Re-running the script leaves existing secrets unchanged and prints the verifying key derived from the stored signing key.

Create the databases

This script creates a database and a login role for each service, using the passwords generated above.

The script expects the following binaries to be installed:

./deploy/gcp/scripts/init-database.sh

The instance has no public IP, so the script assigns one for the duration of the run, restricted to your own address, and removes it again when it finishes.

Share the service account with us

The workload images live in our private Artifact Registry, so the service account that runs the VMs needs read access to it. All three VMs share this one account. Email the output of this command to [email protected]:

tofu -chdir=deploy/gcp/tf/bootstrap-backend output service_account_email

We grant that account roles/artifactregistry.reader on the registry. Until then the VMs boot and exit immediately on a 403 (Forbidden) when pulling the image.

The service account name is derived from prefix, so each new deployment needs its own grant and this procedure must be repeated.

With the policy engine enabled, the policy admin dashboard pulls its image as a Cloud Run service agent instead of this account. That service agent needs its own grant. See Enable the policy engine.