Data collaborators need to set up the following resources for their confidential data to be accessible by a workload:
The encrypted data itself, stored in Google Cloud.
Service accounts that can decrypt that data.
Attestation validation using a workload identity pool (WIP). After a workload has been authorized by the WIP, it can impersonate service accounts in a data collaborator's project to retrieve confidential data.
Additionally, data collaborators need to choose where the results of the Confidential Space workload are stored, and whether the data presented is unique or shared. You could, for example, output the same result to multiple Cloud Storage buckets belonging to each data collaborator.
Store your data
You can use any Google Cloud service that stores data to host your confidential data. For example, you might use one of the following services:
You should make sure this data is encrypted at rest, whether using inbuilt features or with something like Cloud Key Management Service (Cloud KMS).
Create a service account to decrypt confidential data
You make your confidential data available to Confidential Space workloads—and reduce human exposure to that data—through service accounts.
For example, you might encrypt confidential files in Cloud Storage with Cloud KMS, and then create a service account that has permission to access that data and the key to decrypt it.
You then connect that service account to a WIP. An authorized Confidential Space workload based in another project can then use that WIP to impersonate the service account that decrypts the data, retrieve the decrypted data, and process it.
Since service accounts are used to both decrypt the confidential data and process it, confidential data visibility is restricted to its owners. Because the workload operates in a Confidential VM, its hardware-based memory encryption ensures your data stays private while in use. SSH is also disabled on workload VMs using the production Confidential Space image, meaning no one can access the VM while it's running.
See Create your first Confidential Space environment for an example of this.
Create a WIP and provider for attestation validation
To help protect data from an untrusted workload operator, Confidential Space implements an attestation process that detects modifications to a workload image or its TEE. The process is based on Shielded VM measured boot and extended runtime measurements, and captures boot sequence measurements in a protected, extend-only register in the virtual Trusted Platform Module (vTPM) device.
The Confidential Space attestation service generates OpenID Connect (OIDC) tokens that include these vTPM attestations in a form that can be validated by a WIP, which checks them against policies added as attribute conditions to a provider. These tokens are signed by Google, last one hour, and are automatically refreshed.
If the WIP authorizes the workload, the workload can then impersonate service accounts in the project to decrypt and retrieve confidential data.
To set up a WIP and provider, complete the following instructions:
Connect your decrypting service account to the WIP with the
iam.workloadIdentityUser
role.Create an OIDC provider with the following details:
An issuer URI of
https://confidentialcomputing.googleapis.com/
.An allowed audience of
https://sts.googleapis.com
.A provider attribute mapping of
google.subject
, with a value ofassertion.sub
.Attribute conditions that are used to validate the attestations of the workload. See Create an attestation policy for the available options.
Create an attestation policy
As part of creating a WIP, you add attribute conditions—conditions a workload must pass to be able to access your data. For Confidential Space these attribute conditions form your attestation policy.
Policies are written in Common Expression Language
(CEL), and are made up of a series of assertions that can be chained together
with the &&
operator.
Here's an example of adding a provider to a workload identity pool using the
gcloud CLI, along with the attribute-condition
option that defines
the policies:
gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
--location=global \
--workload-identity-pool=user-pool-name \
--issuer-uri="https://confidentialcomputing.googleapis.com/" \
--allowed-audiences="https://sts.googleapis.com" \
--attribute-mapping="google.subject=assertion.sub" \
--attribute-condition="assertion.submods.container.image_digest =='sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b' \
&& 'service-account@my-project.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"
In this example, an external identity attempting to impersonate a service account that's connected to the workload identity pool must attest to and match the following details:
The workload container's image digest
The address of the service account connected to the workload VM
That
CONFIDENTIAL_SPACE
is the software running on the VM, with all of its built-in security guarantees.The production Confidential Space image support attribute
Attestation assertions
The available assertions to construct an attestation policy are detailed in the following table. They can validate assertions made by the Confidential Space image, the workload container, and the VM.
Image assertions
Assertion | Type | Description |
---|---|---|
Interacts with:
|
Defined string |
Verifies that the Confidential Space image is the debug or production version. The valid values are:
ExamplesThe following code verifies that the debug version of the Confidential Space image is being used:
The following code verifies that the production version of the Confidential Space image is being used:
|
assertion.submods.confidential_space.support_attributes |
String array |
Verifies the security version of the TEE is a production Confidential Space image. Debug Confidential Space images have no support attribute set. There are three support attributes:
ExampleThe following code verifies that a stable version of the Confidential Space image is being used:
|
assertion.swname |
Defined string |
Verifies the software running on the attesting entity. The
value is always Example
|
assertion.swversion |
String array |
Verifies the software version of the Confidential Space image. We
recommend using
Example
|
Container assertions
Assertion | Type | Description |
---|---|---|
Interacts with:
|
String array |
Verifies the CMD commands and parameters used in the workload image. ExamplesThe following code verifies the CMD of the workload image hasn't been overwritten:
The following code verifies that
|
Interacts with:
|
JSON object |
Verifies that environment variables and their values have been explicitly passed to the container. ExampleThe following code verifies that the environment variable
|
Interacts with:
|
String |
Verifies if the workload operator has overwritten environment variables in the container. ExamplesThe following code verifies that the workload operator has not
overridden the
The following code verifies that the workload operator hasn't overwritten any environment variables:
|
assertion.submods.container.image_digest |
String |
Verifies the image digest of the workload container. Specifying this condition lets multiple parties agree on an authorized workload that is allowed to access their data. Example
|
assertion.submods.container.image_id |
String |
Verifies the image ID of the workload container. Example
|
Interacts with:
|
String |
Verifies the location of the workload container running on top of the Confidential Space image. Example
|
Interacts with:
|
JSON object |
Verifies that the image has a certain signature or is signed by a public key and signing algorithm. Specifying this condition lets multiple parties agree on an authorized workload that is allowed to access their data. The assertion can include the following elements:
Example
|
Interacts with:
|
Defined string |
Verifies the restart policy of the container launcher for when the workload stops. The valid values are:
Example
|
VM assertions
Assertion | Type | Description |
---|---|---|
Interacts with:
|
String array |
Verifies that a specified service account is connected to the
VM running the workload, or has been listed using
Example
|
assertion.hwmodel |
String |
Verifies the underlying Confidential Computing technology. The
only supported platform is Example
|
Interacts with:
|
Boolean |
Verifies the monitoring state on the attesting entity. Example
|
assertion.submods.gce.instance_id |
String |
Verifies the VM instance ID. Example
|
assertion.submods.gce.instance_name |
String |
Verifies the name of the VM instance. Example
|
assertion.submods.gce.project_id |
String |
Verifies that the VM is running a Google Cloud project with the specified project ID. Example
|
assertion.submods.gce.project_number |
String |
Verifies that the VM is running in a Google Cloud project with the specified project number. Example
|
Interacts with:
|
String |
Verifies that the VM is running in the specified zone. Example
|