Confidential Space provides an isolated environment to operate on sensitive data, while the owners of that data retain confidentiality. Sensitive data might include personally identifiable information (PII), protected health information (PHI), intellectual property, cryptographic secrets, machine learning (ML) models, or otherwise.
You might use Confidential Space to compare sensitive data that's only visible to its original owners and a mutually agreed-upon workload. Alternatively, you could use it to offer end customers stronger data privacy guarantees, as the operator or owner of a Confidential Space environment can't access the data that is being processed.
Confidential Space uses a trusted execution environment (TEE) that can be used to release your secrets only to authorized workloads. An attestation process and hardened OS image help protect the workload and the data that the workload processes from an operator.
For more detail about Confidential Space's use cases and security model, see Confidential Space security overview.
Confidential Space components
A Confidential Space system has three core components:
A workload: A containerized image containing code that has access to the protected resources. This is run on top of a Confidential Space image, a hardened OS based on Container-Optimized OS. This in turn runs on a Confidential VM, a cloud-based TEE that offers hardware isolation and remote attestation capabilities. The workload is located in a separate project from the protected resources.
The attestation service: A remote attestation verifier that returns attestation evidence in the form of OpenID Connect (OIDC) tokens. The tokens contain identification attributes for the workload. The attestation service runs in the same region that the workload is running in.
Protected resources: Managed resources that are protected by an authentication and authorization system. If the resources are in Google Cloud, they can be managed cloud resources such as Cloud Key Management Service (Cloud KMS) keys or Cloud Storage buckets. If the resources aren't in Google Cloud (for example, in an on-premises environment or in another cloud), then they can be any resource.
Confidential Space roles
The components in a Confidential Space system are managed by people with three distinct roles:
Data collaborators: The people or organizations who own the protected resources being operated on by the workload. Data collaborators can access their own data, set permissions on that data, and depending on the workload's output might access results based on that data.
Data collaborators can't access each other's data or modify the workload code.
See Create and grant access to confidential resources to learn more about the role of data collaborators.
Workload author: The person who creates the application that accesses and processes the confidential data. They add the application to a containerized image using Docker, and upload the image to Artifact Registry.
The workload author has no access to the data or the results, and can't control access to them either.
See Create and customize workloads to learn more about the workload author's role.
Workload operator: The person who runs the workload. The workload operator typically has full administrative privileges on the project they run the workload in. For example, in their project they can manage resources such as Compute Engine instances, disks, and networking rules, and can interact with any Google Cloud API that acts on them.
The workload operator has no access to the data, and can't control access to it either. They can't influence or modify the workload code or execution environment.
See Deploy workloads to learn more about the workload operator's role.
A person can assume one or more of these roles. For the highest security, Confidential Space supports a trust model where data collaborators, workload authors, and workload operators are separate, mutually distrusting parties. All roles must collaborate with each other to get the results they need.
An example Confidential Space flow
Confidential Space makes use of multiple Google Cloud services to help private information from multiple sources be operated on confidentially. In general, setting up a Confidential Space might look similar to the following process:
Multiple data collaborators store encrypted confidential data in their own isolated Google Cloud projects, often in different organizations. They want to compare and process that data without revealing it to each other or external parties. The encrypted data might live in Cloud Storage, BigQuery, or another service.
The data collaborators create mock, non-confidential data for a test workload to operate on. This data might be different files, or live in a different place like a separate Cloud Storage bucket.
The data collaborators each create a service account in their projects that can decrypt their data. They connect those service accounts to a workload identity pool (WIP). Later, a workload running in a workload operator's separate, isolated project can use that WIP to impersonate the decrypting service accounts if it passes certain conditions.
The workload author writes code to process the confidential data. In a project separate from the data collaborators and workload operator, they build a containerized image with Docker and upload it to Artifact Registry.
The workload operator creates a service account in an isolated project that has read access to where the data collaborators' encrypted confidential data is stored, and write access to somewhere (for example, a Cloud Storage bucket) to output the result of operating on the decrypted data. Later, this service account is attached to a Confidential VM which runs the workload.
The data collaborators add the Confidential Space attestation verifier as a provider to their workload identity pools. They also add attribute conditions to the provider that the workload must pass to be able to access and decrypt their data. These conditions include verifying the attestations of the workload VM, the image digest of the workload, whether environment variables have been set, and more.
The workload is tested on the non-confidential data by starting a Confidential VM in the workload operator's project. The VM is based on a debug version of the Confidential Space image which loads the containerized workload.
After the VM's attestations are verified and the workload passes the data collaborators' conditions, the service account attached to the VM is allowed to impersonate the decrypting service accounts. The data collaborator service accounts pass the decrypted data onto the workload service account, which processes that data, then outputs a result.
After monitoring and debugging is complete, the workload is updated for production use. The data collaborators update and lock down their workload identity providers further if required, and might choose to test the production workload on non-confidential data first.
All parties sign off on the production workload, and it's ready to begin working on confidential data.
Requirements
Confidential Space requires Confidential VM and Certificate Authority Service to work. These services are available in the locations detailed in the following links:
What's next
Learn more about Confidential Space images.