Deploying on Google Cloud
Google Cloud offers the widest hardware choice of any Polaris cloud: AMD SEV-SNP, Intel TDX, and NVIDIA H100 confidential GPUs. Read Deploying Polaris first for the choices common to every cloud; this page covers what is specific to GCP.
Before you start
You deploy into your own GCP project. The account running the deployment needs enough rights to create confidential VMs, service accounts, a Cloud KMS key ring, an Artifact Registry repository, networking, and, for the deeper attestation modes, Workload Identity Federation. The deploy script checks these up front and stops with a clear message if any are missing, so you find out before anything is created, not halfway through.
You choose the region and zone. They have to offer the confidential-VM shape for the TEE you pick, so settle the TEE choice and the region together.
TEE options
| Choice | Hardware | Machine family |
|---|---|---|
| AMD SEV-SNP | AMD Milan / Genoa | n2d |
| Intel TDX | Intel Sapphire Rapids | c3 |
| NVIDIA H100 confidential GPU | Intel TDX host plus H100 in confidential mode | a3 |
A few things worth knowing when you choose:
- AMD SEV-SNP is the default and the simplest path. Polaris verifies the AMD report directly against AMD's key hierarchy, so no cloud attestation service sits in the trust path.
- Intel TDX runs on Google's
c3shapes and is verified against Intel's published root of trust. - The NVIDIA H100 option requires Intel TDX as the host TEE. It brings up a GPU-enabled confidential VM and binds the GPU's attestation to the CPU's, so the deployment is only healthy when both the CPU and the GPU attest. Because H100 capacity is scarce, these run on Spot VMs by default.
Verification path
GCP is a direct-attestation platform. Clients verify the raw AMD or Intel hardware report against the silicon vendor's keys, with no Google service and no Fr0ntierX service in the verification path. When a confidential GPU is present, the GPU evidence is verified against NVIDIA's attestation service, which is the one outbound dependency in that case.
Key management
The Policy Manager gates a key in Cloud KMS. For the workload and full attestation modes it uses Workload Identity Federation so that key access is tied to the attested identity of the VM rather than a long-lived credential. The key ring and key are created in your project and named after the deployment unless you set your own names.
How you deploy
- Command line. Point the deploy script at a GCP config file. The workload can be a prebuilt image in Artifact Registry or a Dockerfile directory the pipeline builds and pushes for you.
- Google Cloud Marketplace. Deploy from the listing and fill in the options through the marketplace form. The marketplace image ships with the Polaris components baked in, so the confidential VM's deny-by-default egress needs no registry path at boot.
Notes
- GPU deployments allowlist NVIDIA's attestation endpoint for egress, because that is where the GPU evidence is checked. Everything else stays deny-by-default.
- The Cloud KMS key, the service accounts, and the network all live in your project. Tearing down the deployment removes them.