Skip to main content

Enable the policy engine

The policy engine lets you define rules that auth-svc enforces before a signature is produced, for example a spending limit on a transaction. It is optional and off by default.

Turning it on adds two components:

  • policy-svc: evaluates the rules. A Confidential Space VM with no public IP, reachable only by auth-svc.
  • Policy admin dashboard: a web app on Cloud Run where you author the policies. It talks to auth-svc over the VPC, never to policy-svc directly.

It also creates a second Postgres database and two more secrets, and switches auth-svc's FEATURE_POLICY_EVALUATION on.

Additional prerequisites

Enable the Cloud Run API

gcloud services enable run.googleapis.com --project=BACKEND_PROJECT_ID

Grant yourself roles/run.admin

Cloud Run has no firewall: public access is an IAM binding granting allUsers the invoker role on the service, and roles/editor cannot set it. Skip this if you hold roles/owner.

gcloud projects add-iam-policy-binding BACKEND_PROJECT_ID \
  --member="user:$(gcloud config get-value account)" \
  --role=roles/run.admin

Registry access for the Cloud Run service agent

Cloud Run pulls the dashboard image as a Google-managed service agent, not as the service account you configured. It is created automatically when the Cloud Run API is enabled, and looks like:

service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com

Email that address to [email protected] as well. It needs its own roles/artifactregistry.reader grant, separate from the one for the VM service account.

An Auth0 application for the dashboard

The dashboard authenticates its operators through Auth0, using a Regular Web Application, separate from the API the mobile app uses.

Auth0 only redirects back to URLs it knows, so the dashboard's URL must be registered on that application. The URL is deterministic, so you can work it out before the service exists:

https://PREFIX-admin-dashboard-PROJECT_NUMBER.REGION.run.app

Using our predefined configuration? The client ID and secret came with your credentials, and the dashboard runs against our Auth0 tenant. Email that URL to [email protected] and we register it. Until then the dashboard deploys and serves, but sign-in fails.

Using your own Auth0 tenant? Create a Regular Web Application, add URL/auth/callback to its allowed callback URLs and URL/ to its allowed logout URLs. The client ID and secret are on its settings page.

The URL contains your prefix, so changing it means registering the new URL before sign-in works again.

Configure

In deploy/gcp/tf/global.tfvars:

enable_policy_svc = true

auth0_client_id     = "YOUR_AUTH0_CLIENT_ID"
auth0_client_secret = "YOUR_AUTH0_CLIENT_SECRET"
auth0_app_secret    = "YOUR_AUTH0_APP_SECRET"

auth0_app_secret encrypts the dashboard's session cookie and is yours to generate:

openssl rand -hex 32

Apply

The flag is read by all three modules, so apply them in the same order as the initial deployment:

# Adds the policy-svc HMAC key
tofu -chdir=deploy/gcp/tf/bootstrap-secret-guardian apply -var-file=../global.tfvars
./deploy/gcp/scripts/generate-secrets-secret-guardian.sh

# Adds the policy-svc database password and firewall rule
tofu -chdir=deploy/gcp/tf/bootstrap-backend apply -var-file=../global.tfvars
./deploy/gcp/scripts/generate-secrets-backend.sh
./deploy/gcp/scripts/init-database.sh

# Adds the policy-svc VM and the Cloud Run service
tofu -chdir=deploy/gcp/tf/backend apply -var-file=../global.tfvars

If you are turning the engine on for a deployment that is already running, reset auth-svc:

gcloud compute instances reset PREFIX-auth-svc --zone=VM_ZONE --project=BACKEND_PROJECT_ID

The apply updates the VM's metadata but does not restart it, and the container reads its environment only at boot.

Then read the dashboard address:

tofu -chdir=deploy/gcp/tf/backend output admin_dashboard_url

Verify

Open the dashboard URL and sign in with Auth0. You should reach the policy editor.

policy-svc has no public address by design, so there is nothing to open for it. Confirm it is running through its logs, exactly as in Deploy the services. The VM is PREFIX-policy-svc.

Define a policy

Until you author a policy, every signature is rejected. The deployment sets FEATURE_POLICY_NOT_SET_ALLOWS = false, so a user with no policy is denied rather than waved through.

Create one in the dashboard before testing. The fields and an example are in Setting a policy.

In the mobile app

The app must opt in too: turn on Policy evaluation in its Custom Backend settings. See Test with the mobile app.