Create and grant access to confidential resources

Data collaborators need to set up the following resources for their confidential data to be accessible by a workload:

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:

  1. Create the WIP.

  2. Connect your decrypting service account to the WIP with the iam.workloadIdentityUser role.

  3. 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 of assertion.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

assertion.dbgstat

Interacts with:

 Defined string

Verifies that the Confidential Space image is the debug or production version.

The valid values are:

  • enable: Check that the debug image is being used.
  • disabled-since-boot: Check that the production image is being used.
Examples

The following code verifies that the debug version of the Confidential Space image is being used:

assertion.dbgstat == "enable"

The following code verifies that the production version of the Confidential Space image is being used:

assertion.dbgstat == "disabled-since-boot"
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:

  • LATEST: This is the latest version of the image, and is supported. The LATEST image is also STABLE and USABLE.
  • STABLE: This version of the image is supported and monitored for vulnerabilities. A STABLE image is also USABLE.
  • USABLE: An image with only this attribute is out of support and no longer monitored for vulnerabilities. Use at your own risk.
Example

The following code verifies that a stable version of the Confidential Space image is being used:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Defined string

Verifies the software running on the attesting entity. The value is always CONFIDENTIAL_SPACE.

Example
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion String array

Verifies the software version of the Confidential Space image. We recommend using assertion.submods.confidential_space.support_attributes instead to target the latest version of an image.

Example
int(assertion.swversion[0]) == 230103

Container assertions

Assertion Type Description

assertion.submods.container.cmd_override

Interacts with:

 String array

Verifies the CMD commands and parameters used in the workload image.

Examples

The following code verifies the CMD of the workload image hasn't been overwritten:

size(assertion.submods.container.cmd_override) == 0

The following code verifies that program is the only content in the CMD overrides:

assertion.submods.container.cmd_override == ['program']

assertion.submods.container.env

Interacts with:

 JSON object

Verifies that environment variables and their values have been explicitly passed to the container.

Example

The following code verifies that the environment variable example-env-1 is set to value-1, and example-env-2 is set to value-2.

assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}

assertion.submods.container.env_override

Interacts with:

 String

Verifies if the workload operator has overwritten environment variables in the container.

Examples

The following code verifies that the workload operator has not overridden the example environment variable:

!has(assertion.submods.container.env_override.example)

The following code verifies that the workload operator hasn't overwritten any environment variables:

size(assertion.submods.container.env_override) == 0
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_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id String

Verifies the image ID of the workload container.

Example
assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"

assertion.submods.container.image_reference

Interacts with:

 String

Verifies the location of the workload container running on top of the Confidential Space image.

Example
assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"

assertion.submods.container.image_signatures

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:

  • key_id: The hexadecimal fingerprint of the public key. To get the fingerprint, you can run the following command:

    openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256

    Where public_key.pem is your public key in PEM format.

  • signature: The signature over a payload that's associated with the signed container and that follows the Simple Signing format.

  • signature_algorithm: The algorithm used to sign the key. One of the following:

    • RSASSA_PSS_SHA256 (RSASSA-PSS with a SHA-256 digest)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 with a SHA-256 digest)
    • ECDSA_P256_SHA256 (ECDSA on the P-256 Curve with a SHA-256 digest)
Example
assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"

assertion.submods.container.restart_policy

Interacts with:

 Defined string

Verifies the restart policy of the container launcher for when the workload stops.

The valid values are:

  • Never (default)
  • Always
  • OnFailure
Example
assertion.submods.container.restart_policy == "Never"

VM assertions

Assertion Type Description

assertion.google_service_accounts

Interacts with:

 String array

Verifies that a specified service account is connected to the VM running the workload, or has been listed using tee-impersonate-service-accounts in the VM metadata.

Example
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel String

Verifies the underlying Confidential Computing technology. The only supported platform is GCP_AMD_SEV.

Example
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.instance_memory_monitoring_enabled

Interacts with:

 Boolean

Verifies the memory monitoring state on the attesting entity.

Example
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id String

Verifies the VM instance ID.

Example
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name String

Verifies the name of the VM instance.

Example
assertion.submods.gce.instance_name == "workload-vm"
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_id == "project-id"
assertion.submods.gce.project_number String

Verifies that the VM is running in a Google Cloud project with the specified project number.

Example
assertion.submods.gce.project_number == "00000000000"

assertion.submods.gce.zone

Interacts with:

 String

Verifies that the VM is running in the specified zone.

Example
assertion.submods.gce.zone == "us-central1-a"