Skip to content

GCP Confidential Space

This guide takes you from no setup to a full scan of a Confidential Space workload. The scan covers the Workload Identity Federation provider that gates key release, the Cloud KMS key and secrets it protects, the bootstrap bucket, the Confidential VM and its launch metadata, and the attestation token.

Checks: see the GCP Confidential Space check list.

Before you begin

  • Install the CLI: Install.
  • Have Google Cloud credentials for the project. The scanner uses Application Default Credentials, for example gcloud auth application-default login or a service account attached to the machine running the scan.
  • To check the attestation token, capture one from inside the workload and pass the file to the scan.

1. Try the demo

untrust scan --platform sev-snp --demo

The demo needs no credentials and contacts nothing:

[FAIL] CSPACE-KEYBIND-03     WIF provider condition does not require assertion.secboot == true — a VM that did not boot with Secure/Measured Boot could still release the key.
[FAIL] CSPACE-META-01        The workload SA can rewrite the VM's tee-image-reference/tee-cmd metadata — it can run its own code as the attested workload.
[FAIL] CSPACE-LAUNCH-03      tee-cmd overrides the container command — the operator runs their own code as the attested workload.
...
31 of 31 checks failed.
Recorded results: 0 PASS, 31 FAIL, 0 SKIP, 0 ERROR. Skipped checks and errors remain unassessed.

2. Create a scanning identity

Create a service account for the scan and grant it the permissions in Required permissions › GCP Confidential Space. That page is generated from the scanner's code and includes a gcloud iam roles create command for a read-only custom role.

The bootstrap-bucket probe (GCS-BOOT-02) also needs storage.objects.create and storage.objects.delete on the bootstrap bucket. It writes probe objects and then removes them. Scan with --read-only to skip it. Without the write permissions it still runs, and the refused writes show only that the scanning identity cannot write; GCS-BOOT-01 reads the bucket's IAM policy for who else can.

3. Run your first scan

untrust scan --platform sev-snp \
  --gcp-project <project> \
  --wip-provider projects/<project-number>/locations/global/workloadIdentityPools/<pool>/providers/<provider> \
  --gcp-kms-key projects/<project>/locations/<location>/keyRings/<ring>/cryptoKeys/<key> \
  --gcs-bucket <bootstrap-bucket> \
  --gcp-instance <vm> --gcp-zone <zone> \
  --output report.json

You only need one target. Each check whose input you leave out reports SKIP.

4. Cover more checks

To check… Add Turns on
a captured attestation token --attestation-token token.jwt CSPACE-ATT-01, CSPACE-TOKEN-01 and others
the token's audience and replay binding --expected-audience, --expected-nonce CSPACE-ATT-02, CSPACE-ATT-03
who signed the workload image --gcp-approved-signers <fingerprints> CSPACE-SIGNER-01
a Secret Manager secret the workload reads --gcp-secret <secret> CSPACE-SECRET-01
a VPC Service Controls perimeter --access-policy <policy> CSPACE-VPCSC-01

Scan inputs lists every option and the checks that read it.

5. Read the results

  • FAIL: open the check's page from the check list. Each page says what a failure enables and how to fix it.
  • SKIP: the check was not given its input.
  • ERROR: the check could not reach a verdict. A denied permission, or an API that is not enabled in the project, is the usual cause.

SKIP and ERROR are never counted as a pass. See Output and exit codes.

6. Keep it running