Confidential Computing on GCP: Protecting Data While It’s Actually in Use
Data security conversations usually cover two states well: encryption at rest (your data sitting in storage) and encryption in transit (your data moving across a network). There’s a third state that gets far less attention because it’s genuinely harder to protect: data in use — the moment your data is actually decrypted in memory so a CPU can process it. For that brief but critical window, data has traditionally been exposed in plaintext to anything with sufficiently privileged access to the underlying host — a compromised hypervisor, a malicious cloud administrator, or a vulnerability in the virtualization layer itself. Confidential Computing is Google’s answer to that specific gap: hardware-based memory encryption that keeps data encrypted in memory even while it’s actively being processed, using encryption keys the cloud provider itself cannot access.
This isn’t a software feature you can replicate with clever application design — it requires CPU-level hardware support, which is exactly why it’s a relatively recent capability rather than something that’s always existed.
The Three States of Data, and Where the Gap Was
┌───────────────────┬──────────────────────────┬─────────────────────┐│ State │ Traditional protection │ Confidential Computing│├───────────────────┼──────────────────────────┼─────────────────────┤│ At rest │ Disk/storage encryption │ Same, plus this ││ (CMEK, default) │ (already standard) │ ││ In transit │ TLS │ Same, plus this ││ In use │ Historically: plaintext in │ Hardware-encrypted ││ (the gap) │ memory during processing │ memory during processing │└───────────────────┴──────────────────────────┴─────────────────────┘Before Confidential Computing, “the cloud provider could theoretically read your data” was a true statement for the in-use state, no matter how well the other two states were locked down — a hypervisor with sufficiently privileged access could, in principle, inspect a VM’s memory contents. Confidential Computing closes this specific gap using CPU features (AMD SEV, AMD SEV-SNP, and Intel TDX depending on the machine type) that encrypt memory with keys generated and held entirely within the CPU’s hardware, inaccessible even to the hypervisor managing the VM.
Confidential VMs: How They Actually Work
Standard VM Confidential VM───────────── ─────────────────CPU processes data CPU processes datain plaintext in — but memory contentsmemory are encrypted using a │ per-VM key generated ▼ inside the CPU itselfHypervisor could, │in principle, read ▼memory contents Hypervisor sees only encrypted memory — cannot decrypt it even with full host accessEnabling a Confidential VM is, from an operational standpoint, close to trivial — it’s a flag at VM creation time, not a redesign of your application:
gcloud compute instances create my-confidential-vm \ --zone=us-central1-a \ --machine-type=n2d-standard-4 \ --confidential-compute \ --maintenance-policy=TERMINATE \ --image-family=debian-12 \ --image-project=debian-cloudThe --maintenance-policy=TERMINATE requirement is worth noting — Confidential VMs can’t be live-migrated during host maintenance the way standard VMs can, because live migration would require exposing the encrypted memory state during transfer. Instead, the VM is terminated and needs to be restarted, which is a real operational trade-off to plan around for workloads with strict availability requirements.
Confidential GKE Nodes
The same protection extends to Kubernetes nodes, letting you run confidential workloads inside a managed GKE cluster rather than only on standalone VMs:
gcloud container clusters create my-cluster \ --zone=us-central1-a \ --machine-type=n2d-standard-4 \ --enable-confidential-nodesEvery pod scheduled on a confidential node inherits the memory encryption guarantee automatically, without the workload itself needing to be aware it’s running on confidential infrastructure — no code changes, no special libraries. This “transparent to the application” property is one of Confidential Computing’s most practical advantages over alternative approaches to data-in-use protection (like fully homomorphic encryption or secure multi-party computation), which typically require substantial application redesign to use at all.
How Remote Attestation Actually Proves the Guarantee
The claim “this VM has hardware memory encryption enabled” is only trustworthy if something outside the VM can cryptographically verify it — otherwise you’re just trusting a configuration flag, which is exactly the kind of unverifiable claim Confidential Computing is meant to move beyond.
The key property here is that the attestation report is signed by the CPU’s own security processor — not by the VM’s operating system, not by anything the workload itself controls — so a compromised or malicious VM can’t simply lie about its own configuration. A verifying party (the other organization in a multi-party collaboration, for instance) checks the signed report against Google’s attestation service rather than taking the VM’s word for it, which is what turns “we configured this correctly” into “we can cryptographically prove this was configured correctly,” a meaningfully stronger claim for any scenario involving genuine mutual distrust between parties.
Verifying Attestation in Practice, Not Just in Theory
Knowing attestation exists conceptually and actually checking it in a real workflow are different things — a common gap is enabling Confidential VMs correctly but never wiring the attestation verification step into the application logic that’s supposed to depend on it. For a genuine multi-party trust scenario, the verifying party’s code needs to call the attestation verification API explicitly before accepting data or granting access, rather than assuming the --confidential-compute flag alone provides an ongoing guarantee. Treating attestation as a step that happens once at VM boot and is never re-checked is a subtler version of the same gap — for long-running workloads handling a continuous stream of sensitive data, periodic re-verification is a more defensible practice than a single check at startup.
Real-World Use Case: Multi-Party Data Collaboration
A scenario that’s genuinely hard to solve without hardware-backed guarantees: two organizations — say, a healthcare provider and a research institution — want to jointly analyze a combined dataset without either party fully trusting the other’s infrastructure, or trusting a third-party cloud provider with unrestricted access to the sensitive combined data. Confidential Computing enables this kind of collaboration by letting each party cryptographically verify (via remote attestation, which proves a VM is genuinely running with confidential computing enabled and hasn’t been tampered with) that the processing environment has the claimed hardware protections before contributing their data — a technical guarantee that doesn’t rely purely on a legal agreement or trust in the cloud provider’s internal access controls.
Real-World Use Case: Regulated Financial Processing
Financial institutions processing highly sensitive transaction data under strict regulatory requirements are a more everyday, less exotic application of the same underlying capability. Confidential VMs let a bank run fraud-detection or risk-scoring workloads with a documented, hardware-enforced guarantee that transaction data was never exposed in plaintext to the underlying infrastructure at any point in the processing pipeline — a specific, auditable claim that satisfies certain compliance frameworks in a way that “we trust our cloud provider’s access controls” alone doesn’t.
Performance and Cost Considerations
Memory encryption isn’t free — there’s a real performance overhead from the encryption/decryption happening at the memory controller level, though modern hardware implementations (particularly AMD SEV-SNP) have narrowed this gap substantially compared to earlier generations. For most workloads, the overhead is small enough to be a reasonable trade-off for the security guarantee; for extremely latency-sensitive or memory-bandwidth-intensive workloads, benchmarking your actual workload on Confidential VMs before committing is worth the effort rather than assuming the overhead is negligible by default.
Best Practices
- Use remote attestation for genuinely high-trust scenarios, not just the
--confidential-computeflag alone — attestation is what actually proves the guarantee is in effect, rather than trusting configuration intent. - Plan for the live-migration limitation explicitly in availability design — confidential workloads need restart-tolerant architecture since they can’t be seamlessly migrated during host maintenance.
- Combine with CMEK for data at rest and standard TLS for data in transit — Confidential Computing addresses the in-use gap specifically; it’s one layer of a complete encryption strategy, not a replacement for the other two.
- Benchmark performance-sensitive workloads before broad rollout, rather than assuming the overhead is negligible for every workload type.
- Document which specific claims attestation actually proves for your use case. “This VM has confidential computing enabled” and “this VM is running the exact unmodified software we intended” are related but distinct claims, and being precise about which one your architecture actually relies on avoids overstating the guarantee to stakeholders or auditors.
Common Mistakes
Treating Confidential Computing as a general security upgrade rather than a specific gap-closer. It protects data in use specifically — it doesn’t replace IAM access control, network security, or application-level input validation, all of which remain necessary regardless.
Assuming it works identically across all machine types. Confidential Computing requires specific CPU generations and machine families that support the underlying hardware feature (AMD SEV/SEV-SNP or Intel TDX) — not every machine type on GCP supports it, and checking compatibility before architecture decisions avoids a late surprise that forces a machine-type migration mid-project.
Skipping remote attestation for scenarios that actually need the cryptographic proof. Enabling the feature flag without verifying attestation gives you the protection but not the provable guarantee — for multi-party trust scenarios specifically, the attestation is often the entire point.
Frequently Asked Questions
Does Confidential Computing slow down my application significantly? Overhead varies by workload but is generally modest on current hardware generations, particularly AMD SEV-SNP. Memory-bandwidth-heavy workloads see more impact than CPU-bound ones — benchmark your specific case rather than assuming a universal percentage.
Is Confidential Computing the same as a Trusted Execution Environment (TEE)? Yes, conceptually — Confidential VMs and Confidential GKE Nodes are GCP’s implementation of the broader TEE concept, using hardware memory encryption to create an execution environment isolated even from the infrastructure operator.
Can I use Confidential Computing with GPUs for ML workloads? GCP has extended confidential computing support to certain GPU-backed configurations for confidential ML training and inference — availability depends on specific machine types and should be checked against current supported configurations before architecture decisions, since this coverage has expanded gradually rather than being available across every accelerator type from the start.
Do I need to change my application code to run on a Confidential VM? Generally no — the encryption happens transparently at the hardware/hypervisor level. Most workloads run unmodified; the exceptions are scenarios requiring explicit remote attestation verification, which does require integration work.
How is this different from just using Cloud KMS or CMEK? KMS and CMEK protect data at rest — they encrypt data before it’s stored and decrypt it when retrieved. Confidential Computing protects the separate window in between, while the CPU is actively processing already-decrypted data in memory. They address different states of the same data lifecycle and are meant to be used together, not as alternatives to each other.
What’s the practical difference between AMD SEV, SEV-SNP, and Intel TDX? They’re different vendor implementations of the same underlying concept, with SEV-SNP and TDX being newer generations offering stronger protection against certain sophisticated attacks (like memory replay) that basic SEV doesn’t fully address. The choice is typically determined by which machine type family you select rather than an independent decision.
Summary
Confidential Computing closes a gap that was, for most of cloud computing’s history, simply accepted as an inherent trust boundary — data has to be decrypted somewhere to be processed, and that somewhere was traditionally exposed to the infrastructure operator. Hardware-based memory encryption removes that exposure for the specific window data spends in active use, at the cost of a live-migration limitation and a modest performance overhead that’s worth benchmarking rather than assuming. It’s most valuable precisely where “we trust our cloud provider” isn’t a sufficient answer — regulated industries, multi-party data collaboration, and any scenario where a technical, attestable guarantee needs to replace a purely contractual or policy-based one that ultimately just asks stakeholders to trust the operator’s word.