---
title: Google Cloud Research Environment
framework: Private Cloud Compute Security Guide
role: article
role_heading: Article
path: private-cloud-compute/googlecloudresearch
---

# Google Cloud Research Environment

Inspect independently, exercise, and attempt to break the software running on Google Cloud nodes.

## Overview

Overview Google publishes a node’s host image and Apple publishes its workload container; pccvre downloads both, and you can inspect them on your own Mac. Exercising a node is different: its trusted computing base is an x86 confidential-computing stack rooted in Intel TDX, the Titan security chip, and NVIDIA confidential computing, none of which a Mac can emulate. Full-fidelity research therefore runs against real Google Cloud infrastructure rather than a virtualized node on your own machine. The tools and procedures for Inspecting Releases are shared across both platforms. Everything else described here is specific to Google Cloud. Google Cloud Research Tooling covers the tools you use; to independently reproduce a node’s software measurements, see Reproducing Google Cloud Measurements. Research these areas to check PCC’s principles The environment supports these kinds of investigation: Understand how the environment works A Google Cloud node runs on real cloud hardware, and its attestation covers that hardware’s roots of trust. That shapes both how you get access to a node and how you configure its workload: You work against real cloud infrastructure, not a local virtual node. Full-fidelity research requires access to Google Cloud and to managed instances. Running the workload on a Linux VM on a Mac exercises only part of the node’s trusted computing base; it omits the confidential-computing hardware, the multi-vendor roots of trust, and the third-party firmware and drivers that a node’s attestation covers. The environment is expensive to run, so Apple shares reserved capacity. The accelerator-optimized instances a node uses are costly and not always immediately available, which makes a research environment impractical for an individual to run continuously. Apple shares its reserved capacity with invited researchers through time-based reservations. You can instead pay for your own cloud usage and provision the environment yourself, in which case you set up the entire cloud environment rather than draw on Apple’s capacity. An instance you provision runs on a machine type with no GPU attached and no host-attestation support, so its evidence omits both the GPU measurements and the host attestation. Instance management is narrowly scoped and isolated. The Apple-provided environment exposes only specific instance-management operations, for example, launching an instance and changing its configuration. You reach an instance through a tunnel, both for the request data path and for SSH access to a debug-image instance. Google’s Identity-Aware Proxy mediates both network paths, which limits who can reach an instance and keeps the research environment isolated from Apple’s own infrastructure. Authenticating to the proxy requires a Google identity. The workload is a single container, with no separate configuration or tooling delivery. A Google Cloud node packages Apple’s measured runtime, configuration, and tooling into a single attested container image (see Workload Megacontainer), and an instance runs one such workload container. To modify measured configuration or bring your own tools, you modify the workload container. Understand the tooling boundary The pccvre command-line tool that ships with macOS is your starting point for the interactions it covers on both platforms: the transparency log, binary-asset downloads, and request-execution log validation. Use pcc-curl to submit requests to an instance. The boundary between the Apple-provided tools and the rest of the Google Cloud environment falls at interactions with Google Cloud itself. For the infrastructure Apple provides, you interact with the environment through: