Lesson 5.2 · 15 min read
Confidential Space for multi-party workloads
Workload authors, operators and data collaborators, the hardened image, and attestation-gated access via workload identity federation.
The problem it solves
Confidential Space lets several parties combine sensitive data in a workload that none of them, including the party running it, can inspect. It runs a container on a Confidential VM using a hardened, Google-maintained image based on Container-Optimized OS. The Google Cloud attestation service verifies the VM and the workload and issues an OIDC token describing them. Data owners grant access to their resources (for example, decrypting with a Cloud KMS key) only to tokens whose claims match a policy.
| Role | Responsibility |
|---|---|
| Workload author | Builds the container image that processes the data |
| Workload operator | Runs the workload in their project; cannot see the data |
| Data collaborators | Own the data and keys; define which workloads may access them |
The data collaborator writes an attribute condition on their workload identity pool provider. Claim names come from the Confidential Space token reference. A typical condition checks the software name, that the image is the production (stable) variant, and the exact container image digest:
assertion.swname == 'CONFIDENTIAL_SPACE' &&
'STABLE' in assertion.submods.confidential_space.support_attributes &&
assertion.submods.container.image_digest == 'sha256:<approved digest>'Key takeaways
- Confidential Space separates workload author, operator and data collaborators.
- Access is gated by attribute conditions on attestation token claims, especially the image digest.
- Pin the container image by digest, not by tag, and require the production image.
References: Confidential Space overview, Token claims reference.