RCRick Collettesecurity · AI · music · people

Chapter 36

Confidential Computing

Scope. This chapter owns the isolation model, attestation, and the decision of when the trade is worth taking. §8.16 owns Shielded VM, §8.17 owns Confidential VM configuration, and §8.18 owns Secure Boot; none of them is re-explained. The chapter's spine is the trade-off §16.9 established: memory encryption removes the hypervisor from the trust boundary, and the hypervisor is exactly where Google's agentless threat detection sits. Prerequisites. §8.16–§8.18, §16.9 (VM Threat Detection), Chapter 14 (Cloud KMS), §4.3 (Workload Identity Federation). Verified against. Google Cloud console and API surface as of 2026-09, Cloud SDK 583.0.0; every flag and enum resolved with --help; see sources at end.

Confidential computing encrypts memory with a key held by the CPU, so the contents of a running workload are opaque to the hypervisor, to the machine's operator, and to other tenants. It closes the last of the three states — data at rest and in transit were already covered — and it does so by removing Google from the trust boundary for that specific property.

Which is the trade. Removing the platform from the trust boundary also removes it as a place from which to help you. §16.9 is explicit: VM Threat Detection scans "from the hypervisor into the memory of a running guest VM", and Confidential VMs are among the configurations it does not cover. That is the decision this chapter exists to inform, and it is a threat-model question: confidential computing defends against the operator, VM Threat Detection against an intruder in your guest, and most workloads face the second more than the first.

A note on what is verifiable here. Performance figures and exhaustive feature-restriction lists could not be confirmed against a current Google source this session. Where that is so, this chapter says it rather than repeating a plausible number.

36.1 Threat Model §

Confidential computing answers one question — who can read this memory — and it is worth being precise about who that removes and who it does not.

What it removes from the trust boundary:

AdversaryRemoved
The hypervisor and host softwareYes — memory keys are held in hardware, inaccessible to it
A co-tenant on the same physical machineYes
Physical access to memory (cold boot, bus probing)Yes
A Google employee with host-level accessYes, for guest memory

What it does not remove is a longer list: your own code, which is exactly as exploitable inside an encrypted VM; your dependencies, which Chapter 37 owns; the guest operating system, since an attacker with root there is inside the boundary; Google's control plane, which still governs who can stop the instance or snapshot its disk; and data at rest and in transit, which are separate controls (§8.17).

And the cost, which §16.9 owns: VM Threat Detection cannot scan a Confidential VM — its memory scanning works from the hypervisor, and the memory is encrypted against exactly that. Google's agentless rootkit and cryptomining detection is unavailable on these instances, and nothing announces the loss.

The decision rule: use confidential computing where the operator is genuinely in your threat model — sovereignty requirements, multi-party computation, key material handled in the clear. Use the platform's detection everywhere else.

Pitfall. Enabling confidential computing across a fleet "because it is more secure" trades a detection capability you were using for a threat you do not face. Where an instance loses VM Threat Detection, a guest-based detection capability has to replace it, and that has to be planned rather than discovered.

36.2 Confidential VMs §

§8.17 owns turning it on. This section owns which technology to choose and what each one costs.

The SDK's --confidential-compute-type accepts five values, and only three appear in the documentation this book could verify:

ValueTechnologyDocumented
SEVAMD Secure Encrypted VirtualizationYes
SEV_SNPAMD SEV with Secure Nested PagingYes
TDXIntel Trust Domain ExtensionsYes
CCAArm Confidential Compute ArchitectureSDK only
BMSAIBare Metal Secure AISDK only

CCA and BMSAI appear in no documentation page fetched this session. They are accepted by the CLI and this book does not describe their behavior, because it could not verify it.

Live migration is the operational difference and it decides availability design. Google supports live migration for AMD SEV on N2D and C3D machine types only; SEV-SNP and Intel TDX do not support it, so a host maintenance event terminates and restarts those instances. §8.17 carries the flag consequence.

They are not interchangeable. SEV encrypts memory. SEV-SNP adds memory integrity — protection against a hypervisor modifying or replaying memory rather than merely reading it — plus attestation. TDX is Intel's equivalent providing both.

Choose SEV-SNP or TDX against an actively malicious operator, and SEV where the concern is a curious one and availability matters more.

Pitfall. Machine type support is per generation and it changes. A design that fixes a machine family and then adds a confidential requirement usually finds them incompatible, and resizing a fleet is a bigger change than choosing correctly at the start (§8.17).

36.3 Confidential GKE Nodes §

Confidential nodes apply the same hardware protection to GKE, and the configuration surface is smaller than the VM one.

Two flags, at cluster or node pool scope:

gcloud container clusters create rc-saas-prod-gke-02 \
  --region=us-central1 \
  --confidential-node-type=sev_snp \
  --workload-pool=rc-saas-prod-app-01.svc.id.goog

--confidential-node-type takes lowercase values — sev, sev_snp, tdx — where the Compute Engine equivalent takes uppercase. The casing differs between the two commands and it is a real source of failed automation.

--enable-confidential-nodes is the older boolean form; --enable-confidential-storage separately covers the node's local storage rather than its memory.

Per node pool is usually the right scope. A confidential node pool alongside a standard one, with scheduling constraints directing pods, limits both the cost and the detection loss to the workloads that need it.

The GKE consequence of §36.1 is that the node is a Confidential VM, so VM Threat Detection does not scan it. Container Threat Detection instruments the guest kernel rather than reading memory from below, so it is unaffected — the loss is partial rather than total, and that is the compensating control.

Pitfall. Enabling confidential nodes at the cluster changes every node pool, including system pools running Google-managed components. Setting it per node pool keeps the blast radius of both the cost and the compatibility question inside the workloads that asked for it.

36.4 Hardware-Based Isolation §

The isolation is enforced by the CPU rather than by software, which is the source of both its strength and its limits.

The mechanism. Memory is encrypted with a key generated inside the processor package and never exposed outside the protected context — managed by a dedicated security processor on AMD and by the TDX module on Intel. Software outside the boundary, the hypervisor included, sees ciphertext.

Encryption is not integrity, and that distinction is the SEV-versus-SEV-SNP line. Plain memory encryption prevents reading. It does not by itself prevent a malicious hypervisor from remapping, replaying, or corrupting pages. SEV-SNP's Secure Nested Paging adds the integrity guarantee, which is why it is the stronger choice against an active adversary rather than a passive one.

The trust root moves into the hardware vendor. With confidential computing you are trusting AMD's or Intel's implementation instead of Google's hypervisor — a smaller and more scrutinized surface, but not an absence of trust. Vulnerabilities in these technologies have been found and will be again, and mitigating one is a firmware update on Google's schedule, not yours.

Data is decrypted inside the CPU to be processed: the protection is against observation from outside the boundary, not computation on encrypted data.

Pitfall. "Encryption in use" is regularly read as homomorphic encryption — computation on data that is never decrypted. It is not that. The plaintext exists inside the processor, and anything that gets code execution inside the boundary sees it.

36.5 Encryption in Use §

The three states of data have three different controls, and confidential computing supplies the one that was missing.

StateControlOwned by
At restCMEK, CSEK, default encryptionChapter 14
In transitTLS, private connectivity§5.17, §31.9
In useConfidential computingThis chapter

The gap it closes is specific. Without it, sensitive data sits in plaintext in host memory, where the operator could in principle read it. Most organizations accept that implicitly; regulated sectors, sovereignty requirements, and workloads processing other parties' data cannot.

The three are not equivalent in coverage. Encryption at rest protects everything stored; encryption in use protects only what is in memory on a confidential instance. Data written to disk, sent over the network, or logged leaves the boundary immediately — §8.17's pitfall, and the most common way the benefit is lost.

A complete design encrypts all three states with keys you control, and the weakest link decides the outcome. A Confidential VM writing plaintext to an unencrypted disk has moved the exposure rather than removed it.

Performance cost exists and this book does not quantify it. No current Google source with a specific figure was confirmed this session, and the cost varies substantially by workload and technology. Measure it for your workload rather than accepting any published number, including one that appears authoritative.

Pitfall. Encryption in use protects memory from outside the guest. It does nothing about the application logging a secret, writing a debug dump, or sending sensitive fields to a monitoring service — all of which carry the data out of the boundary through channels the design intended.

36.6 Attestation §

Attestation is what turns "I configured a confidential VM" into "this workload proved it is running the code I expect, on genuine confidential hardware, before I gave it a secret."

Two distinct attestation mechanisms exist and are frequently conflated:

MechanismTrust rootWhat it proves
Shielded VM integrity monitoring (§8.16)vTPMThe boot chain matched a known-good baseline
Confidential Space attestationThe confidential hardwareThe workload's identity and image, to a relying party

The second is the one that composes with IAM, and it is the genuinely GCP-specific capability in this chapter. Confidential Space runs a workload in a hardened confidential environment and produces an attestation token: a signed assertion carrying claims about what is running.

Those claims are then used in a Workload Identity Pool provider's attribute condition, exactly as a GitHub Actions token's claims are in §4.7. The claim that matters most is the container image digest, so access can be bound to a specific image rather than to a service account anyone in the project could use.

The consequence is a secret released only to specific running code. A Cloud KMS key granted to a principalSet derived from attestation claims is available only to a workload whose image digest matches — and not to an operator reading the project's IAM policy.

That is the multi-party computation pattern: several parties each grant a key to one attested workload, none trusting the others or the operator, all trusting the attestation.

Pitfall. An attestation is only as strong as the condition written against it. A provider that accepts any attestation from the project, without pinning the image digest, proves the workload ran in Confidential Space and nothing about what ran — which is the same failure as an unpinned federation condition (§26.4), with more machinery in front of it.

36.7 Sensitive Workloads §

The decision framework, stated as the question to ask rather than as a list of use cases.

Ask whether the platform operator is in your threat model. If the honest answer is no — and for most workloads it is no, because you have already accepted Google as a trusted operator for everything else — then confidential computing is buying protection against an adversary you are not defending against, at the cost of a detector you are using.

Where the answer is yes:

SituationWhy
Multi-party computationThe parties do not trust each other, and none trusts the operator
Sovereignty requirementsA regulation names operator access specifically
Key material handled in plaintextThe material's whole value is that nobody else sees it
Processing another party's regulated dataYour contract may assert operator opacity

Distinguish this from Assured Workloads (§30.5), which constrains who at Google may support the environment and where data may live. Confidential computing makes the question moot for memory specifically. They compose.

Plan the detection replacement explicitly. A confidential workload has lost VM Threat Detection (§16.9). On GKE, Container Threat Detection still applies (§36.3); on a VM it means a guest agent, which an in-guest attacker can disable — the exact property §16.9 praises the agentless scanner for not having.

Pitfall. Confidential computing is easy to mandate and hard to unwind. A policy requiring it estate-wide will meet machine-type incompatibility, live-migration constraints on SEV-SNP and TDX, and the silent loss of a detector across the fleet. Scope it to the workloads whose threat model justifies it, and record why each one qualifies.

Chapter Summary §

  • Confidential computing removes the hypervisor, the operator, and co-tenants from the trust boundary for guest memory — and removes the platform as a place from which to help you.
  • §16.9's trade-off is the chapter's spine: VM Threat Detection scans memory from the hypervisor, and a Confidential VM's memory is encrypted against exactly that. You cannot have both on one instance.
  • It does not protect against your own code, your dependencies, a compromised guest OS, or Google's control plane.
  • --confidential-compute-type accepts SEV, SEV_SNP, TDX, CCA, and BMSAI; only the first three could be verified against documentation, and this book describes only those.
  • Live migration is supported for AMD SEV on N2D and C3D only; SEV-SNP and TDX instances terminate and restart on host maintenance.
  • SEV encrypts memory; SEV-SNP and TDX add memory integrity. Encryption prevents reading, not modification, and the trust root moves to the hardware vendor rather than disappearing.
  • GKE's --confidential-node-type takes lowercase sev, sev_snp, tdx where Compute Engine takes uppercase — a real source of failed automation.
  • Container Threat Detection instruments the guest kernel and is unaffected by memory encryption, making it the compensating control on a confidential node pool — which is a reason to scope confidential nodes per pool rather than per cluster.
  • "Encryption in use" is not homomorphic encryption: plaintext exists inside the CPU, and code execution inside the boundary sees it.
  • Data written to disk, sent over the network, or logged leaves the boundary immediately. No performance figure here could be verified; measure it for your workload.
  • Confidential Space produces an attestation token whose claims — notably the container image digest — can be used in a Workload Identity Pool attribute condition.
  • That allows a Cloud KMS key to be released only to a workload running a specific image, which is the multi-party computation pattern.
  • An attestation condition that does not pin the image digest proves the workload ran in Confidential Space and nothing about what ran.
  • Ask whether the platform operator is genuinely in your threat model. For most workloads the answer is no. Assured Workloads addresses a related problem differently and composes with this; neither replaces the other.

Security Checklist §

ControlWhy it mattersHow to verify (CLI + Console)
Confidential instances documented with a threat-model justificationIt trades a detector for protection against a specific adversaryThe exception register, per workload
Detection replacement planned for every confidential instanceVM Threat Detection is silently unavailable (§16.9)Guest agent inventory; Container Threat Detection status
Technology chosen against the adversary modelSEV encrypts; SEV-SNP and TDX add integritygcloud compute instances describe NAME --zone=ZONE --format='value(confidentialInstanceConfig)'
Live-migration behavior accounted for in availability designSEV-SNP and TDX terminate on host maintenanceInstance scheduling.onHostMaintenance and machine type
Confidential nodes scoped per node poolCluster scope changes system pools toogcloud container node-pools describe POOL --cluster=CLUSTER --region=REGION
GKE flag values lowercase, Compute Engine uppercaseThe casing differs between the two commandsThe automation that sets them
Attestation conditions pin the image digestOtherwise the attestation proves only the environmentWorkload identity pool provider attribute condition
KMS key release bound to attestation claimsThis is what makes the key unavailable to an operatorKey IAM policy principalSet members

Sources §