Crear recursos confidenciales y conceder acceso a ellos

Los colaboradores de datos deben configurar los siguientes recursos para que una carga de trabajo pueda acceder a sus datos confidenciales:

  • Datos cifrados, almacenados en Google Cloud.

  • Un grupo de identidades de carga de trabajo (WIP) para autorizar la carga de trabajo. Una vez que una carga de trabajo ha sido autorizada por un WIP, puede acceder a los datos confidenciales de los colaboradores de datos y operar con ellos.

Además, los colaboradores de datos deben elegir dónde se almacenan los resultados de la carga de trabajo del espacio confidencial y si esos resultados son únicos para cada colaborador o se comparten. Por ejemplo, puedes enviar el mismo resultado a varios segmentos de Cloud Storage que pertenezcan a cada colaborador de datos.

.

Almacenar datos cifrados

Puedes usar cualquier Google Cloud servicio que almacene datos para alojar tus datos confidenciales. Por ejemplo, puedes usar uno de los siguientes servicios:

Debes asegurarte de que estos datos estén cifrados en reposo, ya sea mediante funciones integradas o con Cloud Key Management Service (Cloud KMS).

Autorizar la carga de trabajo con un WIP

Un WIP es el mecanismo que usa Confidential Space para permitir que una carga de trabajo externa acceda a tus datos confidenciales y trabaje con ellos como una identidad federada. Una identidad federada es una entidad externa que se trata como si fuera una entidad de seguridad de tu proyecto, lo que te permite asignarle roles de gestión de identidades y accesos para darle acceso a recursos específicos o suplantar la identidad de cuentas de servicio para hacer lo mismo.

Como colaborador de datos, debes configurar un proveedor en un WIP que defina las reglas para que las entidades se autentiquen como identidad federada. En el caso de Confidential Space, debe definir lo siguiente en un proveedor:

  • Un servicio de certificación: este servicio verifica que la carga de trabajo es una instancia de VM confidencial y, en última instancia, devuelve un token de certificación OpenID Connect (OIDC) al proveedor de WIP. El operador de la carga de trabajo define el servicio de certificación que se utiliza, que debe coincidir con el servicio de certificación añadido al proveedor de WIP para que se conceda el acceso.

  • Asignaciones de atributos: atributos de los tokens de acceso del servicio de tokens de seguridad que se asignan a aserciones realizadas por la entidad de autenticación (en este caso, la instancia de VM que ejecuta la carga de trabajo). Las aserciones las realizan la propia instancia de VM, la imagen de Confidential Space y el contenedor de la carga de trabajo, y la carga de trabajo las transfiere al proveedor de WIP. Estos atributos se usan para elementos como los registros de auditoría de Cloud Logging y para asignar roles a través de gestión de identidades y accesos en función de las aserciones de entidades de autenticación, como los resúmenes de contenedores de imágenes de cargas de trabajo. Consulte más información sobre las asignaciones de atributos.

  • Una política de certificación: una serie de condiciones que las entidades que se autentican deben cumplir para obtener acceso, en función de las aserciones que hagan.

Cuando se inicia una carga de trabajo, el Launcher de Confidential Space envía su informe de certificación a un servicio de certificación definido por el operador de la carga de trabajo, que verifica la instancia de VM confidencial y, a continuación, devuelve un token de certificación OIDC. Este token dura una hora y se actualiza automáticamente.

A continuación, la carga de trabajo envía el token de certificación al proveedor de WIP, y este lo usa para comprobar que las aserciones cumplen la política de certificación definida en el proveedor. Si es así, la carga de trabajo podrá acceder a los recursos confidenciales.

Acceso a cargas de trabajo externas

Antes de configurar un WIP y un proveedor, debes elegir cómo accederá la carga de trabajo a tus recursos: acceso directo a los recursos o suplantación de identidad de una cuenta de servicio.

Acceso directo a recursos

Recomendamos el método de acceso directo a recursos para las cargas de trabajo.

Este método consiste en configurar una identidad federada en un proveedor de WIP vinculada a las aserciones de una entidad de autenticación. De esta forma, se puede autorizar una carga de trabajo para que acceda a los recursos directamente a través de las vinculaciones de IAM, en función de atributos como el digest de la imagen del contenedor de la carga de trabajo.

El acceso directo a los recursos tiene las siguientes ventajas:

  • Configurar un entorno de Espacio Confidencial requiere menos pasos, ya que los colaboradores de datos no tienen que configurar cuentas de servicio para que una cuenta de servicio de carga de trabajo suplante su identidad.

  • La carga de trabajo solo puede acceder a recursos específicos según lo determinado por IAM. Este método es más seguro que la suplantación de identidad de cuentas de servicio, ya que las cuentas de servicio con demasiados permisos o los derechos de suplantación de identidad pueden proporcionar a un agente malintencionado más acceso del previsto.

  • Cada acceso a recursos se registra con la identidad federada de una instancia de VM de carga de trabajo, en lugar de con la identidad de una cuenta de servicio suplantada que podrían compartir varias cargas de trabajo. La identidad de una instancia de VM de carga de trabajo puede incluir detalles como el digest de la imagen de un contenedor, el número de proyecto desde el que opera la carga de trabajo y el ID de la instancia de VM que ejecuta la carga de trabajo, lo que proporciona un registro de auditoría más detallado.

  • No es necesario que asigne la propiedad de la instancia de VM selfLink al atributo google.subject de un proveedor de WIP. Los valores selfLink muy largos pueden superar el límite de 127 bytes de este atributo, lo que provoca que falle la autenticación del proveedor de WIP.

Suplantación de identidad de cuentas de servicio

El método de suplantación de identidad de la cuenta de servicio implica que cada colaborador de datos configura una cuenta de servicio para descifrar sus datos privados y, a continuación, vincula esa cuenta de servicio a su propio WIP. También especifican la cuenta de servicio de la carga de trabajo en su proveedor de WIP, lo que permite que la cuenta de servicio de la carga de trabajo suplante las cuentas de servicio de los colaboradores de datos para que pueda recuperar y operar con sus datos confidenciales.

La suplantación de identidad de cuentas de servicio solo debe usarse en los siguientes casos:

Es posible que el método de suplantación de la cuenta de servicio no pueda autenticarse en un proveedor de WIP si una instancia de VM tiene una propiedad selfLink muy larga. Esto se debe a que la reclamación sub del token de certificación, que se define con el valor selfLink, se asigna en el proveedor de WIP al atributo google.subject, que tiene un límite de 127 bytes.

En el caso de los valores de selfLink de las instancias de VM que superen los 127 bytes, debe cambiar el nombre de las instancias de VM para acortar el selfLink o usar el método de acceso directo a recursos.

Configurar un WIP y un proveedor

Los pasos para configurar un proveedor varían en función de si usas el acceso directo a recursos o la suplantación de identidad de cuentas de servicio.

Acceso directo a recursos

El método de acceso directo a recursos implica configurar un WIP y un proveedor, y, a continuación, configurar roles de IAM basados en un digest de imagen de contenedor de una carga de trabajo específica.

Configurar un WIP y un proveedor

Para configurar un WIP y un proveedor, sigue estas instrucciones:

  1. Crea el WIP:

    gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
    --location=global

  2. Crea un proveedor de OIDC en el WIP:

    gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
    --issuer-uri="https://confidentialcomputing.googleapis.com/" \
    --allowed-audiences="https://sts.googleapis.com" \
    --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
    --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
        && 'STABLE' in assertion.submods.confidential_space.support_attributes"

    En este ejemplo se usan los siguientes valores:

    • Un issuer-uri de https://confidentialcomputing.googleapis.com/, lo que significa que se usa Google Cloud Attestation como servicio de certificación.

    • Un allowed-audiences de https://sts.googleapis.com. Se trata del servicio de tokens de seguridad de Google, que intercambia credenciales por tokens de acceso.

    • Un attribute-mapping de google.subject con el siguiente valor:

      \"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest

      Este valor se crea con el lenguaje de expresión común (CEL). Los siguientes valores se asignan al atributo gcpcs y se muestran en Cloud Logging cada vez que la carga de trabajo accede a los recursos:

      • assertion.submods.container.image_digest: el digest de la imagen del contenedor de la carga de trabajo.

      • assertion.submods.gce.project_number: número de proyecto de la instancia de VM.

      • assertion.submods.gce.instance_id: ID de la instancia de VM.

      Además, attribute.image_digest se define como assertion.submods.container.image_digest, el digest de la imagen del contenedor de la carga de trabajo. Este atributo se asigna para que puedas conceder roles de gestión de identidades y accesos a la identidad federada en función de un digest específico de la imagen.

      Puedes asignar cualquiera de las aserciones de carga de trabajo disponibles, siempre que la longitud total del valor de google.subject sea inferior a 127 bytes.

    • Los siguientes attribute-conditions, que forman una política de certificación. Si estas condiciones coinciden con las aserciones de la carga de trabajo, se le permitirá acceder a los recursos confidenciales como identidad federada:

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica que Confidential Space es el software que se ejecuta en la VM, con todas sus garantías de seguridad integradas.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica que se esté usando la imagen de producción de Confidential Space y que tenga el STABLE atributo support.

      Para ver más condiciones de atributos que puedes usar, consulta Crear una política de certificación.

Concede los roles de gestión de identidades y accesos de la identidad federada

Una vez que hayas creado un proveedor de WIP, puedes asignar a la identidad federada un rol de gestión de identidades y accesos en función de si el digest del contenedor de la imagen de la carga de trabajo de la identidad coincide con un valor esperado.

En el siguiente ejemplo se muestra cómo conceder a una identidad federada la capacidad de descifrar una clave específica de Cloud Key Management Service:

gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/attribute.image_digest/WORKLOAD_CONTAINER_IMAGE_DIGEST" \
    --role=roles/cloudkms.cryptoKeyDecrypter

Suplantación de identidad de cuentas de servicio

El método de suplantación de identidad de la cuenta de servicio implica lo siguiente:

  1. Crear cuentas de servicio en cada uno de los proyectos de colaboradores de datos y concederles permiso para descifrar los datos confidenciales.

  2. Crear WIPs en cada uno de los proyectos de colaborador de datos y, a continuación, adjuntar la cuenta de servicio de cada proyecto que se acaba de crear a su WIP.

  3. Crear proveedores de WIP en cada WIP que especifiquen la cuenta de servicio de la carga de trabajo como la cuenta que tiene permiso para suplantar las cuentas de servicio de colaborador de datos.

Configurar cuentas de servicio para descifrar datos confidenciales

  1. Crea las cuentas de servicio en los proyectos de colaborador de datos:

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Concede a las cuentas de servicio los permisos necesarios para descifrar los datos confidenciales. Por ejemplo, puedes cifrar archivos confidenciales en Cloud Storage con Cloud KMS, por lo que debes conceder permiso a la cuenta de servicio para descifrar esos datos:

    gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member=serviceAccount:DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
    --role=roles/cloudkms.cryptoKeyDecrypter

Configurar un WIP y un proveedor

Para configurar un WIP y un proveedor, siga estas instrucciones en cada proyecto de colaborador de datos:

  1. Crea el WIP:

    gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
    --location=global

  2. Asocia la cuenta de servicio que se va a suplantar al WIP con el rol roles/iam.workloadIdentityUser:

    gcloud iam service-accounts add-iam-policy-binding \
    DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/*" \
    --role=roles/iam.workloadIdentityUser

  3. Crea un proveedor de OIDC en el WIP y define la cuenta de servicio de carga de trabajo en él para que pueda suplantar la cuenta de servicio de colaborador de datos:

    gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
    --location=global \
    --workload-identity-pool=DATA_COLLABORATOR_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 == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' \
&& 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts \
&& assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes"

    En este ejemplo se usan los siguientes valores:

    • Un issuer-uri de https://confidentialcomputing.googleapis.com/, lo que significa que se usa Google Cloud Attestation como servicio de certificación.

    • Un allowed-audiences de https://sts.googleapis.com. Se trata del servicio de tokens de seguridad de Google, que intercambia credenciales por tokens de acceso.

    • Un attribute-mapping de google.subject, con el valor assertion.sub. Es el selfLink de la instancia de VM, tal como se define en la reclamación sub del token de certificación.

      La instancia de VM selfLink aparece en Cloud Logging cada vez que la carga de trabajo accede a los recursos.

    • Los siguientes attribute-conditions, que forman una política de certificación. Si estas condiciones coinciden con las aserciones de la carga de trabajo, se le permitirá acceder a los recursos como identidad federada:

      • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': Verifica que el digest de la imagen del contenedor de la carga de trabajo coincida con el valor esperado.

      • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: Verifica que la cuenta de servicio adjunta a la carga de trabajo coincida con la cuenta de servicio esperada y, a continuación, la usa para suplantar la identidad de la cuenta de servicio del colaborador de datos.

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica que Confidential Space es el software que se ejecuta en la VM, con todas sus garantías de seguridad integradas.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica que se esté usando la imagen de producción de Confidential Space y que tenga el STABLE atributo support.

      Para ver más condiciones de atributos que puedes usar, consulta Crear una política de certificación.

Crear una política de certificación

Para crear un WIP, debes crear una política de certificación. Las aserciones de una entidad de autenticación deben coincidir con tu política para poder acceder a tus datos.

Las políticas se escriben en lenguaje de expresión común (CEL) y se componen de una serie de instrucciones que se pueden encadenar con el operador &&.

Las instrucciones usan aserciones de la imagen de Confidential Space, la imagen del contenedor de la carga de trabajo o la instancia de VM como variables, y el valor que hayas especificado como expresión. Por ejemplo, esta es una política que exige que la carga de trabajo use un espacio confidencial, que debe usar una STABLEimagen de espacio confidencial y que la zona en la que se ejecuta la instancia de VM de la carga de trabajo debe ser us-central1-a:

assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes" \
&& assertion.submods.gce.zone == "us-central1-a"

Consulta más información sobre las afirmaciones de atestación.

Aserciones de atestación

Las aserciones disponibles para crear una política de certificación se detallan en la siguiente tabla. Las políticas pueden validar las aserciones realizadas por la imagen de Confidential Space, el contenedor de la carga de trabajo y la instancia de VM.

Afirmaciones sobre imágenes

Aserción Tipo Descripción

assertion.dbgstat

Interactúa con:

 Cadena definida

Verifica que la imagen de Confidential Space sea la versión de depuración o de producción.

Los valores válidos son:

  • enable: comprueba que se esté usando la imagen de depuración.
  • disabled-since-boot: comprueba que se esté usando la imagen de producción.
Ejemplos

El siguiente código verifica que se está usando la versión de depuración de la imagen de espacio confidencial:

assertion.dbgstat == "enable"

El siguiente código verifica que se esté usando la versión de producción de la imagen de Confidential Space:

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Matriz de cadenas

Verifica que la versión de seguridad del TEE sea una imagen de Confidential Space de producción. Las imágenes de espacio confidencial de depuración no tienen ningún atributo de compatibilidad definido.

Hay tres atributos de asistencia:

  • LATEST: esta es la versión más reciente de la imagen y se admite. La imagen LATEST también es STABLE y USABLE.
  • STABLE: esta versión de la imagen es compatible y se monitoriza para detectar vulnerabilidades. Una imagen STABLE también es USABLE.
  • USABLE: Las imágenes que solo tienen este atributo ya no se admiten y no se monitorizan para detectar vulnerabilidades. Úsalo bajo tu propia responsabilidad.
  • EXPERIMENTAL: una imagen que solo tenga este atributo utiliza las funciones de vista previa. Solo se puede usar con fines de prueba y nunca en producción. Una imagen EXPERIMENTAL nunca tiene los atributos LATEST, STABLE ni USABLE.
Ejemplo

El siguiente código verifica que se esté usando una versión estable de la imagen de espacio confidencial:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Cadena definida

Verifica el software que se ejecuta en la entidad de certificación. El valor siempre es CONFIDENTIAL_SPACE.

Ejemplo
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Matriz de cadenas

Verifica la versión de software de la imagen de Confidential Space. Te recomendamos que utilices assertion.submods.confidential_space.support_attributes para orientar a la versión más reciente de una imagen.

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

Aserciones de contenedor

Aserción Tipo Descripción

assertion.submods.container.cmd_override

Interactúa con:

 Matriz de cadenas

Verifica los comandos CMD y los parámetros utilizados en la imagen de la carga de trabajo.

Ejemplos

El siguiente código verifica que el CMD de la imagen de la carga de trabajo no se haya sobrescrito:

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

El siguiente código verifica que program es el único contenido de las anulaciones de CMD:

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

assertion.submods.container.env

Interactúa con:

 Objeto JSON

Verifica que las variables de entorno y sus valores se hayan transmitido explícitamente al contenedor.

Ejemplo

El siguiente código verifica que la variable de entorno example-env-1 esté definida como value-1 y example-env-2 esté definida como value-2.

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

assertion.submods.container.env_override

Interactúa con:

 Cadena

Verifica si el operador de carga de trabajo ha sobrescrito las variables de entorno en el contenedor.

Ejemplos

El siguiente código verifica que el operador de carga de trabajo no haya sustituido la variable de entorno example:

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

El siguiente código verifica que el operador de la carga de trabajo no haya sobrescrito ninguna variable de entorno:

size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest Cadena

Verifica el digest de la imagen del contenedor de la carga de trabajo. Al especificar esta condición, varias partes pueden acordar una carga de trabajo autorizada que tenga permiso para acceder a sus datos.

Ejemplo
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id Cadena

Verifica el ID de la imagen del contenedor de la carga de trabajo.

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

assertion.submods.container.image_reference

Interactúa con:

 Cadena

Verifica la ubicación del contenedor de carga de trabajo que se ejecuta en la parte superior de la imagen de Confidential Space.

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

assertion.submods.container.image_signatures

Interactúa con:

 Objeto JSON

Verifica que la imagen tenga una firma determinada o que esté firmada por una clave pública y un algoritmo de firma. Si especifica esta condición, varias partes podrán acordar una carga de trabajo autorizada que tenga permiso para acceder a sus datos.

La aserción puede incluir los siguientes elementos:

  • key_id: huella digital hexadecimal de la clave pública. Para obtener la huella digital, puedes ejecutar el siguiente comando:

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

    Donde public_key.pem es tu clave pública en formato PEM.

  • signature: firma sobre una carga útil asociada al contenedor firmado y que sigue el formato de firma simple.

  • signature_algorithm: el algoritmo usado para firmar la clave. Uno de los siguientes:

    • RSASSA_PSS_SHA256 (RSASSA-PSS con una digestión SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 con una digestión SHA-256)
    • ECDSA_P256_SHA256 (ECDSA de curva P-256 con una síntesis SHA-256)
Ejemplo
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

Interactúa con:

 Cadena definida

Verifica la política de reinicio del lanzador de contenedores cuando se detiene la carga de trabajo.

Los valores válidos son:

  • Never (predeterminado)
  • Always
  • OnFailure
Ejemplo
assertion.submods.container.restart_policy == "Never"

Aserciones de VM

Aserción Tipo Descripción

assertion.google_service_accounts

Interactúa con:

 Matriz de cadenas

Verifica que una cuenta de servicio especificada esté conectada a la VM que ejecuta la carga de trabajo o que se haya incluido en los metadatos de la VM mediante tee-impersonate-service-accounts .

Ejemplo
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel Cadena

Verifica la tecnología de Confidential Computing subyacente. Las plataformas admitidas son las siguientes:

  • GCP_AMD_SEV
  • INTEL_TDX
Ejemplo
assertion.hwmodel == "GCP_AMD_SEV"

assertion.submods.confidential_space.monitoring_enabled

Interactúa con:

 Booleano

Verifica el estado de la monitorización en la entidad de certificación.

Ejemplo
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id Cadena

Verifica el ID de la instancia de VM.

Ejemplo
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name Cadena

Verifica el nombre de la instancia de VM.

Ejemplo
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id Cadena

Verifica que la VM esté ejecutando un Google Cloud proyecto con el ID de proyecto especificado.

Ejemplo
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number Cadena

Verifica que la VM se ejecuta en un Google Cloud proyecto con el número de proyecto especificado.

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

assertion.submods.gce.zone

Interactúa con:

  • Operador de carga de trabajo: el --zone valor.
 Cadena

Verifica que la VM se esté ejecutando en la zona especificada.

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

assertion.submods.nvidia_gpu.cc_mode

Interactúa con:

 Cadena definida

Verifica el estado del controlador de computación confidencial de NVIDIA. Los valores válidos son:

  • OFF: ninguna de las funciones de Confidential Computing de NVIDIA está activa.
  • ON: el hardware, el firmware y el software de NVIDIA H100 han activado por completo las funciones de computación confidencial.
  • DEVTOOLS: la GPU está en un modo de computación confidencial parcial que coincide con los flujos de trabajo del modo ON, pero inhabilita las protecciones de seguridad.
Ejemplo
assertion.submods.nvidia_gpu.cc_mode == "ON"