Confidential VMs on GCP, in depth

Who is protected from whom

Start with who is protected from whom. A Confidential VM protects your guest's memory from the layers below it: the hypervisor, the host operating system, cloud operators, and, to varying degrees by technology, attacks on the physical memory bus. It does not protect you from the layers inside the guest. A vulnerable web application, a stolen SSH key, a malicious package in your container image or an over-privileged service account all still work exactly as before, because they run inside the encrypted boundary with the keys already in hand.

It also changes who you trust rather than removing trust. You now rely on the CPU vendor's hardware and firmware, the confidential computing firmware Google runs for the VM, and your own boot chain. Side-channel attacks on these processors are an active research area, and the vendors issue firmware and microcode fixes; treat the protection as defence in depth, not as a guarantee that makes other controls optional. Network traffic and disk I/O leave the guest through memory the host can read, so keep TLS and disk encryption on.

The technologies and what each adds

Compute Engine offers three CPU technologies and one GPU extension. They differ in what they protect and in what you can attest to.

The important line is between SEV and the other two. SEV encrypts memory, but the hypervisor still controls the guest's page mappings, so a malicious hypervisor could swap or replay encrypted pages it cannot read. SEV-SNP and TDX add integrity: the hardware tracks which guest owns each physical page and refuses mappings the guest did not accept. If your threat model includes a compromised host rather than only a curious one, SEV-SNP or TDX is the honest choice.

How memory protection works

From first principles, the processor holds a secret key per VM inside its security unit, the AMD Secure Processor or the Intel TDX module. The memory controller encrypts each cache line with that key on its way to DRAM and decrypts it on the way back, so the guest sees plaintext and anyone reading DRAM or the host's view of guest memory sees ciphertext. The key never leaves the processor, and the hypervisor never learns it.

Devices are the complication. A virtual network card or disk controller is emulated by the host, and the host cannot read private pages, so the guest kernel copies I/O data through a small region of explicitly shared, unencrypted memory, often called bounce buffers. Two consequences follow. First, I/O-heavy workloads pay an extra copy, which is where most of the performance cost of a Confidential VM shows up; compute-bound work sees little. Second, anything in that shared region is visible to the host, which is why the guest must use encrypted protocols over the virtual devices. The guest kernel must also understand all of this, which is why only images marked as supporting each technology will boot.

Creating and enforcing Confidential VMs

Creating one is a normal instance creation with three extra decisions: the technology, a machine type that supports it, and a maintenance policy that matches it. Live migration is supported only for SEV on N2D and C3D, so those use MIGRATE; everything else must use TERMINATE. For TDX, omit --min-cpu-platform.

# Find images whose guest OS declares SEV-SNP support
gcloud compute images list \
    --filter="guestOsFeatures[].type:(SEV_SNP_CAPABLE)"

# SEV-SNP on N2D: integrity protection, no live migration
gcloud compute instances create ledger-worker-1 \
    --zone=us-central1-a \
    --machine-type=n2d-standard-8 --min-cpu-platform="AMD Milan" \
    --confidential-compute-type=SEV_SNP \
    --maintenance-policy=TERMINATE \
    --image-project=ubuntu-os-cloud --image-family=ubuntu-2404-lts-amd64

# Intel TDX on C3: no --min-cpu-platform
gcloud compute instances create ledger-worker-2 \
    --zone=us-central1-a --machine-type=c3-standard-8 \
    --confidential-compute-type=TDX --maintenance-policy=TERMINATE \
    --image-project=ubuntu-os-cloud --image-family=ubuntu-2404-lts-amd64

# Inside the guest: did the kernel come up confidential?
sudo dmesg | grep -iE 'sev|tdx'

The other image capability flags are SEV_CAPABLE, SEV_LIVE_MIGRATABLE_V2 and TDX_CAPABLE. The dmesg check is useful for debugging, but it is not proof: a compromised host could run an ordinary VM that prints the same lines. Proof comes from attestation.

To make sure nobody quietly creates ordinary VMs where confidential ones are required, enforce the organisation policy constraint constraints/compute.restrictNonConfidentialComputing on the folder or project. On GKE, node pools created with --enable-confidential-nodes run every node as a Confidential VM, so pods get the same protection without per-workload changes; the machine type must support the chosen technology. GKE covers node pools in general.

Attestation and key release

Attestation answers the question "is this really a Confidential VM, running the software I expect?" with a report signed by something the host cannot forge. There are two kinds. The vTPM, available on all Confidential VMs, records measurements of the boot chain (firmware, boot loader, kernel) as Shielded VM measured boot does, and signs a quote over them. The hardware report is signed by the AMD Secure Processor for SEV-SNP or by the TDX module for TDX, and covers the hardware and firmware environment of the VM itself; on SEV-SNP it can be requested at any time. The open-source go-tpm-tools project can request both kinds from inside the guest, and Google Cloud Attestation can verify vTPM quotes and return a signed token describing the VM.

A report on its own changes nothing. It becomes a control when a secret, a database password or a data-encryption key, is released only to a VM whose verified claims match a policy. The verifier must include a fresh nonce in the request so an old report cannot be replayed. Google's Confidential Space product packages this pattern for container workloads; if you build it yourself, the logic looks like this sketch.

# Key-release service (pseudocode). Runs outside the confidential VM.
def release_key(request):
    nonce = request.nonce
    if not nonce_store.consume(nonce):          # issued by us, unused, fresh
        deny("stale or unknown nonce")

    claims = verify_token(request.attestation_token,   # signature + expiry
                          trusted_issuer=ATTESTATION_ISSUER)
    if claims.nonce != nonce:
        deny("token not bound to this request")

    policy = {
        "tee_type":      {"SEV_SNP", "TDX"},       # SEV alone not accepted
        "secure_boot":   True,
        "project":       "payments-prod",
        "image_digest":  APPROVED_IMAGE_DIGESTS,   # pinned, reviewed builds
        "debug_enabled": False,
    }
    for field, allowed in policy.items():
        if not matches(claims.get(field), allowed):
            deny(f"claim {field} failed")          # log the full claim set

    return kms.decrypt(WRAPPED_DATA_KEY)           # short-lived, per-VM

The field names in the sketch are illustrative; map them to the claims your verifier actually returns. Store the wrapped key in Secret Manager or Cloud KMS, and grant decryption to the key-release service only, never directly to the VM's service account, otherwise an ordinary VM with the same identity could skip the check.

Operational limits

Most surprises are operational, and several are specific to the stronger technologies:

• Maintenance means a restart. Outside SEV on N2D and C3D, a host maintenance event stops the VM. Run at least two instances behind a load balancer or a managed instance group, and handle the shutdown signal. Compute Engine in depth explains maintenance events and the metadata you can watch.
• No reservations for SEV-SNP or TDX. You cannot pin capacity with a reservation, so a large fleet can meet a stockout during a scale-out or a zone failover. Spread across zones and keep headroom.
• No kdump on SEV-SNP or TDX. A kernel crash leaves no dump to analyse; ship logs off the VM continuously.
• Shape limits. TDX supports up to 192 vCPUs and cannot run on sole-tenant node groups, and SEV and SEV-SNP on N2D and C2D are limited to eight vNIC queues, which caps network throughput for very chatty services.
• Images matter. An image without the right guest OS feature will not boot as a Confidential VM, and custom images need the feature declared when they are built.

Worked example: a payments workload

A payments team runs a nightly reconciliation job over cardholder data and a small always-on API that scores transactions. Their auditors ask for evidence that the cloud operator cannot read the data while it is processed. The team's choices, in order:

1. Technology. The threat model includes a compromised host, so SEV is out. They choose SEV-SNP on N2D for the batch job and the API, accepting no live migration.
2. Availability. The API runs as a regional managed instance group of three n2d-standard-8 instances with TERMINATE, so a maintenance event costs one instance for a few minutes, not the service. The batch job checkpoints its progress to Cloud Storage every ten minutes and restarts on a new VM if stopped.
3. Key release. The data-encryption key for the cardholder files is wrapped in Cloud KMS. Each VM fetches a nonce, obtains a hardware-backed attestation token and calls the key-release service, whose policy pins the approved image digests and requires SEV-SNP and Secure Boot.
4. Guardrails. The project carries the restrict-non-confidential-computing constraint, so a mis-typed template fails at creation instead of running unprotected.
5. Evidence. The key-release service logs every decision with the full claim set, which becomes the audit trail.

The measurable cost was operational rather than computational: an image pipeline that publishes digests, a small verifier service and runbooks for restarts. The VM's own overhead was small for the CPU-bound scoring and larger for the I/O-heavy reconciliation, which they measured before committing.

Failure modes

• Encrypted but unattested. Secrets are baked into the image or fetched with a plain service account, so an ordinary VM with the same identity receives them too. Gate secrets on attestation.
• Policy pinned to a moving target. The allow-list names an image family rather than digests, so any new image passes. Pin digests and update them through review.
• Nonce omitted. A captured token can be replayed from another machine. Bind every token to a fresh, single-use nonce.
• Wrong maintenance policy. MIGRATE is supported only for SEV on N2D and C3D; a template that worked there breaks when someone switches its technology to SEV-SNP or TDX without changing the policy to TERMINATE.
• Debug access left open. Serial console or broad SSH access into an attested VM lets an operator read data the hardware was protecting. Restrict them like production database access.

Trade-offs

SEV gives the widest machine choice and live migration with the weakest guarantee. SEV-SNP and TDX give integrity and stronger attestation at the price of no live migration, no reservations and no kdump. GPU confidential computing protects accelerated workloads but is limited to specific shapes. Against all of them, weigh whether the threat you face is below the guest at all: if your real risks are application bugs and stolen credentials, a Confidential VM does not reduce them, and the effort is better spent on IAM and patching. Where regulation or contracts require that the provider cannot see data in use, a confidential VM with enforced attestation is the most direct way to show it.

What to do next

1. Write down the threat model: which party must not see the data, and whether a compromised host is in scope. That decides SEV versus SEV-SNP or TDX.
2. Check which machine series and zones support that technology today, and confirm your image declares the matching guest OS feature.
3. Create one test VM with the correct maintenance policy, then request a hardware report and a vTPM quote from inside it.
4. Build a key-release path: nonce, token verification, a policy pinned to image digests, and KMS decryption granted only to the verifier.
5. Plan availability without live migration: multiple instances, checkpoints and restart runbooks.
6. Enforce constraints/compute.restrictNonConfidentialComputing on the projects that hold the protected data.