Prepare and test your skills
Prepare and test your skills
Google Cloud Confidential Computing Services protect data in use by keeping code and data encrypted in memory inside a hardware-based trusted execution environment (TEE) (opens in a new tab). A TEE is a secure area inside the processor that protects the confidentiality and integrity of code and data loaded inside it. Confidential Computing completes end-to-end encryption by adding encryption in use to encryption at rest and encryption in transit. Google Cloud divides this work among Confidential VM, Confidential GKE Nodes (opens in a new tab), and Confidential Space based on workload shape and trust requirements.
How Confidential Computing protects data in use is defined by four hardware-backed properties that isolate processing from the rest of the system. Runtime encryption means the processor keeps TEE data encrypted in memory, so direct reads reveal only ciphertext and direct writes cannot change plaintext. Isolation means the processor blocks software access from outside the TEE and allows communication only over defined interfaces. Attestation and data lifecycle security prove the environment is genuine and keep protection applied during processing, not only during storage or movement.
The four properties work together to enable private analytics, secure collaboration, and breach resistance:
Confidential VM is a type of virtual machine that uses hardware-based memory encryption to protect data and applications while in use. Confidential VM provides isolation and attestation, and Google Cloud builds on it for Compute Engine, Confidential Dataflow, Confidential Dataproc, Google Kubernetes Engine, and Vertex AI Workbench. Supported hardware includes AMD SEV, AMD SEV-SNP, Intel TDX, Arm CCA, IBM Z, IBM LinuxONE, and Nvidia Confidential GPU. Confidential GPUs extend the same model to accelerated computing with hardware encryption and isolation on the GPU, so even the cloud provider or malicious actors cannot access data during GPU processing.
Confidential VM shrinks the trust boundary so fewer layers can reach plaintext. Without Confidential Computing, the boundary includes Google Cloud infrastructure, hypervisor, host operating system, BIOS and firmware, and guest operating system. With Confidential VM, the cloud stack and administrators, BIOS and firmware, and host operating system and hypervisor move outside the boundary, while the VM guest administrator, guest operating system, applications, and confidential data remain inside. Choose Confidential VM when a VM workload needs memory encryption without restructuring the application, including lift-and-shift sensitive processing, streaming analytics, and batch data processing.
Confidential GKE Nodes encrypt data in use for container workloads on Google Kubernetes Engine (GKE). Confidential GKE Nodes run as Confidential VMs, so container memory is hardware-encrypted and isolated from the host operating system, hypervisor, and cloud administrator. This service depends on a compatible machine type, zone, GKE version, and node operating system, and both cluster control planes and nodes must be in a location that supports the selected technology.
Configuration of Confidential GKE Nodes can apply at the cluster or node-pool level or at the workload level with a ComputeClass. A ComputeClass is a Kubernetes custom resource that defines attributes of new nodes that GKE creates and controls fallback behavior if confidential hardware is not available. ComputeClass supports all available Confidential Computing technologies for GKE even when a technology is not supported at the cluster or node-pool level. Version requirements include the following:
Choose Confidential GKE Nodes when containerized applications need data-in-use protection with Kubernetes orchestration, including confidential analytics pipelines, containerized model training, and mixed clusters where only selected workloads require confidential hardware.
Confidential Space creates a secure area within a VM that provides the highest level of isolation for sensitive data and applications. Confidential Space adds defense in depth on top of Confidential VM technology by isolating applications from vulnerabilities in the guest operating system. The service provides granular control over access inside the secure environment and stronger assurance of confidentiality and integrity through measurement and attestation.
Confidential Space shrinks the trust boundary to just the application and its memory space. The cloud stack and administrators, BIOS and firmware, host operating system and hypervisor, and VM guest administrator all sit outside the boundary. The VM guest operating system and applications remain inside only as measured and attested components, alongside the confidential data itself. Choose Confidential Space for highly sensitive regulated workloads or multi-party collaboration, such as joint fraud-model training across banks, collaborative drug discovery, or digital clean rooms where data flows to the TEE only after attestation claims are validated.
Exam tip: Confidential VM removes the host operating system, hypervisor, BIOS, and cloud administrator from the trust boundary but keeps the VM guest administrator inside, while Confidential Space also removes the VM guest administrator and requires the guest operating system and applications to be measured and attested.
Attestation and trust verification is the process that proves a Confidential VM instance is legitimate and in an expected state before data is released. During attestation, the CPU chip supporting the TEE produces a cryptographically signed attestation report covering bootloader activity, hardware configuration, firmware configuration, and other boot-time logged events. An attestation for process isolation authenticates an application, while an attestation for VM isolation authenticates a VM, the virtual firmware used to launch the VM, or both.
Attestation reports are generated by the Confidential VM instance and signed by a software-based virtual Trusted Platform Module (vTPM) or a hardware-based Trusted Security Module (TSM). The Google-managed vTPM covers bootloader activity and kernel integrity, while the AMD Secure Processor and Intel Trust Domain Extensions (TDX) module provide hardware-rooted coverage of hardware and firmware. For Intel TDX, initial launch firmware is measured into the Measurement of the Trust Domain (MRTD) and the remaining boot chain is measured into Runtime Measurement Registers (RTMR), and users can extend RTMR[3] with user-space measurements. Reports are requested with Go-TPM and Go-TPM tools, using version 0.4.4 or later for AMD SEV-SNP and Intel TDX, with SEV Guest for AMD SEV-SNP challenges and TDX Guest for Intel TDX challenges. The GceNonHostInfo event in the vTPM event log (opens in a new tab) shows which technology is in use.
Choosing the appropriate service for sensitive data in use starts from where the data is processed and who must be excluded from access. The three services differ by workload unit, trust boundary, and collaboration model:
| Service | Primary unit | Trust boundary retains | Choose when |
|---|---|---|---|
| Confidential VM | VM with encrypted memory | VM guest administrator, guest operating system, applications, and data | Workload runs on VMs and needs protection from host, hypervisor, and cloud administrator without application redesign |
| Confidential GKE Nodes | GKE node pool or ComputeClass-backed nodes for containers | VM guest administrator, guest operating system, applications, and data | Workload runs in containers and needs Kubernetes scheduling, with confidential hardware for all nodes or only selected workloads |
| Confidential Space | Attested application and memory space inside a VM | Only measured and attested guest operating system and applications, plus data | Workload involves multiple parties, regulated data, or untrusted guest administrators and requires data release only after attestation |
A federated learning architecture shows the distinction. A federated server runs in a TEE cluster, clients train locally on bank-specific encrypted transaction data, and only aggregated model weights return through a secure aggregation protocol. Confidential VM or Confidential GKE Nodes fits single-organization processing (opens in a new tab) where the operator controls the guest, while Confidential Space fits collaboration where competing banks, hospitals, or agencies must not expose raw data to each other, to the operator, or to the infrastructure.
Analyze the architecture and security properties of trusted execution environments means examining how hardware isolation protects data during processing from cloud provider access and other tenants. A trusted execution environment (TEE) (opens in a new tab) is a secure area within a processor that protects the confidentiality and integrity of code and data loaded inside it. The TEE completes end-to-end encryption by adding protection for data while it is being processed, alongside encryption at rest for stored data and encryption in transit for moving data.
Core security properties of a confidential computing environment are four hardware-backed guarantees that together protect data in use. Runtime encryption keeps environment data encrypted in memory, isolation blocks unauthorized software access, attestation proves trustworthiness, and data lifecycle security extends hardware protection into the processing phase. Attestation for process isolation authenticates an application, while attestation for VM isolation authenticates a virtual machine (VM), the virtual firmware used to launch the VM, or both.
The properties connect as a chain from processor to data owner:
Application-based versus VM-based trusted execution environments differ by the size of the protected unit. Secure enclaves protect selected application code and data, while confidential VMs and confidential graphics processing units (GPUs) protect entire VMs and accelerator workloads with memory encryption and attestation:
| Environment | Isolation model | Example technologies |
|---|---|---|
| Secure enclaves, also known as application-based confidential computing | Isolate code and data from the operating system using hardware-based isolation or by placing the hypervisor within the trusted computing base (TCB), so even users with physical or root access cannot learn enclave memory contents or tamper with execution | Intel Software Guard Extensions (SGX) |
| Confidential VMs and confidential GPUs, also known as VM-based confidential computing | Use hardware-based memory encryption to protect data and applications for a whole VM or GPU workload, with isolation and attestation | AMD Secure Encrypted Virtualization (SEV), AMD SEV-Secure Nested Paging (SNP), Intel Trust Domain Extensions (TDX), Arm Confidential Compute Architecture (CCA), IBM Z, IBM LinuxONE, and Nvidia Confidential GPU |
Google Cloud uses Confidential VM to enable confidential computing for VM workloads and extends the same VM-based protection to containers through Confidential GKE (opens in a new tab), to streaming analytics through Confidential Dataflow, and to data processing through Confidential Dataproc. Confidential GPUs apply hardware-based encryption and isolation to data while it is being processed on the GPU, which protects accelerated computing in cloud and shared environments even from the cloud provider or malicious actors.
Exam tip: Intel SGX is application-based and isolates an enclave from the operating system, while AMD SEV, AMD SEV-SNP, and Intel TDX are VM-based and use hardware memory encryption for a full VM.
Hardware isolation and trust boundary reduction removes cloud infrastructure from the path to plaintext. Without confidential computing, the trust boundary includes Google Cloud infrastructure with hardware, hypervisor, and host OS, plus BIOS and firmware, host OS and hypervisor, cloud stack and administrators, VM guest administrator, VM guest OS, applications, and confidential data. When a workload runs in a Confidential VM, memory stays encrypted and the processor blocks host software access, so cloud stack and administrators, BIOS and firmware, and host OS and hypervisor move outside the boundary and only the guest OS, guest administrator, application, and data remain inside.
With Confidential Space, which creates a secure area within a VM for joint analysis and highly sensitive workloads, the VM guest administrator also moves outside the boundary. The remaining guest OS and applications are measured and attested, leaving only the application, its associated memory space, and confidential data as the minimal trusted set. This shift protects data from co-tenants and host administrators because a memory dump yields only ciphertext, and host software cannot invoke enclave or confidential-VM internals except through defined interfaces. In collaborative designs, each participant keeps private encrypted data locally and releases data to the TEE aggregation or federated server only after validating attestation claims.
Attestation architecture and measurement roots describe how a data owner verifies a TEE before trusting it with keys or plaintext. The TEE instance generates an attestation report with measurements of bootloader activity, hardware configuration, firmware configuration, and other boot-time logged events, the CPU signs the report, and the signed measurement flows to an attestation service for validation. The type of report depends on the technology in use, and the GceNonHostInfo event in the vTPM attestation event log shows which technology is active.
Attestation reports differ by signing source and coverage. The Google-managed vTPM provides software-based attestation covering bootloader activity and kernel integrity. The AMD Secure Processor provides hardware-based attestation from a Trusted Security Module (TSM) for AMD SEV-SNP, and the Intel TDX module provides hardware-based attestation from a TSM for Intel TDX. For Intel TDX, initial launch firmware is measured into MRTD and the remaining boot chain into RTMR, with users able to extend RTMR[3] with user-space measurements. Reports can be requested with Go-TPM and Go-TPM tools version 0.4.4 or later for AMD SEV-SNP and Intel TDX support. For hardware-only challenges, SEV Guest requests reports from the AMD Secure Processor with Version Chip Endorsement Key (VCEK) certificates cached on the VM, and TDX Guest requests reports from the Intel TDX module. The AMD Secure Processor is shared by all hosts on its physical server, so a host can throttle guest access and firmware updates can occur at any time as host events. Details of report types and verification flows are covered in Confidential VM attestation (opens in a new tab), while key-transfer controls that depend on attestation are covered by the Split-Trust Encryption Tool (opens in a new tab).
Design solutions for end-to-end data protection with Confidential Computing means keeping data encrypted across all three lifecycle states: at rest, in transit, and in use. Google Cloud encrypts stored data and data moving across physical boundaries by default, and Confidential Computing (opens in a new tab) completes the strategy by keeping data encrypted in memory while it is processed inside a hardware-based trusted execution environment (TEE).
End-to-end encryption across the data lifecycle covers three states with different risks. Encryption at rest protects data while stored in systems such as Cloud Storage, BigQuery, or disks. Encryption in transit protects data when it moves between two points, such as from on-premises to cloud or between microservices. Encryption in use protects data while it is processed in CPU memory, where it would otherwise be decrypted for computation.
Confidential Computing provides that third piece, encryption in use. Without it, an administrator, hypervisor, host operating system, or attacker with direct memory access could read plaintext during processing. With it, data flows from encrypted storage over an encrypted connection into an encrypted memory enclave, is decrypted only inside the processor boundary, and results leave the enclave encrypted for storage or transmission.
How a trusted execution environment protects data in use is by acting as an isolated safe room inside the processor for sensitive operations. A hardware-based TEE is a secure area within the processor that protects the confidentiality and integrity of code and data loaded inside it, so data can remain encrypted in memory even if the surrounding system is compromised. The environment provides runtime encryption, isolation, attestation, and data lifecycle security as linked properties.
Attestation creates the trust decision that gates the workflow. First, the CPU chip supporting the TEE produces a cryptographically signed attestation report with a measurement of the instance. Then, the measurement flows from the TEE to an attestation service for verification. Only after validation does the data owner release decryption keys or encrypted data to the TEE. An attestation for process isolation authenticates an application, while an attestation for VM isolation authenticates a virtual machine (VM), the virtual firmware used to launch the VM, or both.
Confidential computing technology choices divide into two families by isolation scope. Secure enclaves, also called application-based confidential computing, isolate specific code and data from the operating system with hardware isolation. Confidential VMs and confidential GPUs, also called VM-based confidential computing, encrypt entire VM memory and isolate whole workloads.
Secure enclaves are designed so even users with physical or root access cannot learn enclave memory contents or tamper with code inside the enclave, with Intel Software Guard Extensions (SGX) as an example. Confidential VMs use hardware-based memory encryption with isolation and attestation, using AMD SEV, AMD SEV-SNP, Intel TDX, Arm CCA, IBM Z, IBM LinuxONE, and Nvidia Confidential GPU. Confidential GPUs extend hardware encryption and isolation to GPU processing for AI training and inference where the cloud provider or other tenants must not see sensitive data. Choose application-based enclaves when only a small sensitive function needs isolation, and choose Confidential VM or Confidential GPU when an entire VM, container, data pipeline, or AI accelerator workload must run with encrypted memory.
Google Cloud Confidential Computing portfolio maps workload shapes to encrypted-in-use execution. Confidential VM technology also extends into Dataflow, Managed Service for Apache Spark, Google Kubernetes Engine, and Vertex AI Workbench, letting teams keep existing pipeline, orchestration, and notebook workflows while adding in-use encryption.
The portfolio includes five workload mappings plus two supporting controls:
Two supporting controls complete the portfolio. Google Cloud Attestation verifies TEE measurements before keys or data are released. The Split-Trust Encryption Tool (STET) (opens in a new tab) enables secure key transfer in and out of Google Cloud using two key management systems (KMS), one internal to Google Cloud and one external, so compromise of one KMS alone does not expose data. Configuration details for container workloads that use this portfolio are documented for Confidential GKE Nodes (opens in a new tab).
Split-trust integration with at-rest and in-transit encryption layers client-side encryption, external key management, confidential execution, and split trust so no single layer sees both plaintext and keys. Data flows from on-premises compute to a Cloud Storage bucket, then from the bucket to Compute Engine VMs or managed services for processing. Protection increases across five levels:
Shrinking the trust boundary defines which layers must be trusted with confidential data. Without confidential computing, cloud infrastructure, host software, and guest software are all trusted. With confidential computing, hardware, hypervisor, host operating system, firmware, and cloud administrators move outside the boundary. With Confidential Space, even the VM guest administrator moves outside:
| Layer | Without Confidential Computing | With Confidential Computing | With Confidential Space |
|---|---|---|---|
| Cloud stack and administrators | Inside boundary | Outside boundary | Outside boundary |
| BIOS, firmware, host OS, and hypervisor | Inside boundary | Outside boundary | Outside boundary |
| VM guest admin | Inside boundary | Inside boundary | Outside boundary |
| VM guest OS and applications | Inside boundary | Inside boundary, guest OS unmeasured | Inside boundary, measured and attested |
| Confidential data | Inside boundary | Inside boundary, memory-encrypted | Inside boundary, isolated to app memory space |
Confidential Space creates a secure area within a VM for the highest isolation. Its benefits are defense in depth on top of Confidential VM, reduced attack surface by isolating applications from guest OS vulnerabilities, granular control over access inside the secure environment, and stronger assurance of confidentiality and integrity. Choose Confidential Space for highly sensitive regulated workloads and multi-party collaboration where participants do not trust each other or the guest administrator.
Exam tip: Confidential Computing alone still trusts the VM guest admin and guest OS, while Confidential Space removes the guest admin and requires measured and attested guest OS and applications.
Architecting workflows that preserve confidentiality end to end combines encrypted data sources, attestation-gated release, isolated aggregation, and encrypted return of results. In confidential analytics, confidential AI, and confidential federated learning, bank-specific or provider-specific encrypted data remains encrypted until attestation claims from the TEE are validated, and only then does data flow from each collaborator to the TEE.
In the confidential analytics architecture for healthcare, multiple providers, biopharmaceutical, and research institutions collaborate without exposing raw records. Each partner operates a local environment between its private encrypted patient data, including electronic health records, and a TEE OLAP aggregation server. Data flows from each partner to the TEE only after attestation validation, training and inference run inside the TEE protected from the operating system and cloud provider, and an analytics client runs confidential queries. In the confidential AI architecture for finance, banks jointly train a fraud model without exposing transaction data or fraud labels. A pre-trained base model from a model repository is packaged as containers for TEE model training, encrypted bank data flows into the TEE after attestation validation, the global model trains inside the TEE with federated learning or secure multi-party computation, and improved weights flow back for local deployment. In the confidential federated learning architecture, the model moves to the data. A federated server in a TEE cluster sends an initial model to local inference engines at each bank, each engine trains on local private encrypted transaction data, then sends only model updates back through a secure aggregation protocol that reveals only element-wise weighted averages from a random subset, not individual updates. The federated server aggregates updates into a global model, and aggregated weights flow back for local inference. Techniques such as homomorphic encryption and differential privacy can further protect weights, and transferring only weights improves network efficiency and data sovereignty. Reference designs for these patterns are described in confidential computing for data analytics, AI, and federated learning (opens in a new tab).
Google Cloud Confidential Computing protects data in use by keeping code and data encrypted in memory inside a hardware-based trusted execution environment (TEE), which is a secure area inside the processor that protects confidentiality and integrity. It completes end-to-end encryption by adding encryption in use to encryption at rest and encryption in transit through runtime encryption, isolation, attestation, and data lifecycle security.
Use Confidential VM when a workload runs on virtual machines and needs hardware-based memory encryption without restructuring the application, including protection from the host, hypervisor, and cloud administrator. Use Confidential GKE Nodes when containerized applications need data-in-use protection with Kubernetes orchestration for all nodes or only selected workloads. Use Confidential Space when a workload involves multiple parties, regulated data, or untrusted guest administrators and requires data release only after attestation validation.
Attestation proves a Confidential VM instance is legitimate and in an expected state before data is released, starting when the CPU chip supporting the trusted execution environment (TEE) produces a cryptographically signed attestation report covering bootloader activity, hardware configuration, firmware configuration, and other boot-time logged events. The signed measurement flows to an attestation service for validation, with reports signed by a software-based virtual Trusted Platform Module (vTPM) covering bootloader activity and kernel integrity or by a hardware-based Trusted Security Module (TSM) from the AMD Secure Processor or Intel Trust Domain Extensions module.
A multinational financial services institution is migrating a mission-critical payment processing system to Google Cloud. The compliance and security teams mandate a comprehensive, end-to-end data protection strategy that enforces strict data confidentiality across all stages of the data lifecycle:
Which architecture meets all of these end-to-end data protection requirements?
Last updated