Crear y otorgar acceso a recursos confidenciales

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

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

Almacena tus datos encriptados

Puedes usar cualquier servicio Google Cloud 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 encriptados en reposo, ya sea con funciones integradas o con algo como Cloud Key Management Service (Cloud KMS).

Autoriza 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 principal dentro de tu propio proyecto, lo que te permite otorgarle roles de IAM para darle acceso a recursos específicos o suplantar cuentas de servicio para hacer lo mismo.

Como colaborador de datos, configuras un proveedor dentro de un WIP que establece las reglas para las entidades que se autentican como una identidad federada. En el caso de Confidential Space, debes definir lo siguiente en un proveedor:

  • Un servicio de certificación: Este servicio verifica que la carga de trabajo sea una instancia de VM confidencial y, en última instancia, devuelve un token de certificación de OpenID Connect (OIDC) al proveedor de WIP. El operador de carga de trabajo establece el servicio de certificación que se usa, y debe coincidir con el servicio de certificación agregado al proveedor de WIP para que se otorgue el acceso.

  • Asignaciones de atributos: Son atributos en los tokens de acceso del Servicio de tokens de seguridad que se asignan a aseveraciones realizadas por la entidad de autenticación, en este caso, la instancia de VM que ejecuta la carga de trabajo. La instancia de VM, la imagen de Confidential Space y el contenedor de carga de trabajo realizan las aserciones, y la carga de trabajo las pasa al proveedor de WIP. Estos atributos se usan para elementos como los registros de auditoría en Cloud Logging y para otorgar roles a través de IAM en función de las aserciones de entidades de autenticación, como los resúmenes de contenedores de imágenes de cargas de trabajo. Obtén más información sobre las asignaciones de atributos.

  • Una política de certificación: Es una serie de condiciones que las entidades de autenticación deben cumplir para obtener acceso, según las afirmaciones que realicen.

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, luego, devuelve un token de certificación de OIDC. Este token dura una hora y se actualiza automáticamente.

Luego, la carga de trabajo pasa el token de certificación al proveedor de WIP, y este lo usa para verificar que las aserciones pasen la política de certificación definida en el proveedor. Si es así, se le permite a la carga de trabajo 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 la cuenta de servicio.

Acceso directo a recursos

Te recomendamos el método de acceso directo a los recursos para las cargas de trabajo.

Este método implica configurar una identidad federada en un proveedor de WIP vinculado a las aserciones de una entidad de autenticación. De esta manera, se puede autorizar una carga de trabajo para acceder a los recursos directamente a través de vinculaciones de IAM, según atributos como el resumen de la imagen de contenedor de la carga de trabajo.

El acceso directo a recursos tiene las siguientes ventajas:

  • Configurar un entorno de Confidential Space requiere menos pasos, ya que los colaboradores de datos no necesitan 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 determina IAM. Este método es más seguro que el de suplantación de identidad de la cuenta de servicio, en el que las cuentas de servicio con permisos excesivos o los derechos de suplantación de identidad pueden proporcionar a un actor malicioso más acceso del previsto.

  • Cada acceso a los recursos se registra con la identidad federada de la instancia de VM de la carga de trabajo, en lugar de la identidad de una cuenta de servicio suplantada que podría compartir varias cargas de trabajo. La identidad de una instancia de VM de carga de trabajo puede incluir detalles como el resumen 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 asignes la propiedad de instancia de VM selfLink al atributo google.subject en 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.

Uso de identidad temporal como cuenta de servicio

El método de suplantación de identidad de la cuenta de servicio implica que cada colaborador de datos configure una cuenta de servicio para desencriptar sus datos privados y, luego, adjunte 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 a las cuentas de servicio del colaborador de datos para que pueda recuperar y operar con sus datos confidenciales.

El robo de identidad de cuentas de servicio solo debe usarse en las siguientes situaciones:

Es posible que el método de suplantación de identidad 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 declaración sub en el token de certificación, que se establece en 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 instancias de VM que superen los 127 bytes, debes cambiar el nombre de tus instancias de VM para acortar el selfLink o usar el método de acceso directo al recurso.

Configura un WIP y un proveedor

Los pasos para configurar un proveedor cambian según si usas acceso directo a recursos o la suplantación de identidad de una cuenta de servicio.

Acceso directo a recursos

El método de acceso directo a recursos implica configurar un WIP y un proveedor, y, luego, configurar roles de IAM basados en un resumen específico de la imagen del contenedor de carga de trabajo.

Configura un WIP y un proveedor

Para configurar un WIP y un proveedor, completa las siguientes 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.

    • Es un allowed-audiences de https://sts.googleapis.com. Este es el 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 construye con Common Expression Language (CEL). Los siguientes valores se asignan al atributo gcpcs y aparecen en Cloud Logging cada vez que la carga de trabajo accede a los recursos:

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

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

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

      Además, attribute.image_digest se establece en assertion.submods.container.image_digest, el resumen de la imagen del contenedor de carga de trabajo. Este atributo se asigna para que puedas otorgar roles de IAM a la identidad federada según un resumen de imagen específico.

      Puedes asignar cualquiera de las aserciones de carga de trabajo disponibles, siempre que la longitud total del valor 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 permite acceder a los recursos confidenciales como una identidad federada:

      • assertion.swname == 'CONFIDENTIAL_SPACE': Verifica que Confidential Space sea 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 Confidential Space de producción y que tenga el STABLE atributo de asistencia.

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

Otorga roles de IAM a la identidad federada

Después de crear un proveedor de WIP, puedes otorgar a la identidad federada un rol de IAM según si el resumen 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 otorgar a una identidad federada la capacidad de desencriptar 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

Uso de identidad temporal como cuenta de servicio

El método de identidad temporal como cuenta de servicio implica lo siguiente:

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

  2. Crear WIP en cada uno de los proyectos de colaborador de datos y, luego, 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 puede suplantar las cuentas de servicio de los colaboradores de datos

Configura cuentas de servicio para desencriptar datos confidenciales

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

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Otorga a las cuentas de servicio los permisos necesarios para desencriptar los datos confidenciales. Por ejemplo, puedes encriptar archivos confidenciales en Cloud Storage con Cloud KMS, por lo que debes otorgar permiso a la cuenta de servicio para desencriptar 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

Configura un WIP y un proveedor

Para configurar un WIP y un proveedor, completa las siguientes 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. Conecta la cuenta de servicio que se 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 en él la cuenta de servicio de la carga de trabajo para que pueda suplantar la cuenta de servicio del 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.

    • Es un allowed-audiences de https://sts.googleapis.com. Este es el 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, como se define en el reclamo 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 permite acceder a los recursos como una identidad federada:

      • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': Verifica que el resumen 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, luego, la usa para actuar en nombre de la cuenta de servicio del colaborador de datos.

      • assertion.swname == 'CONFIDENTIAL_SPACE': Verifica que Confidential Space sea 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 Confidential Space de producción y que tenga el STABLE atributo de asistencia.

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

Crea una política de certificación

Como parte de la creación de un WIP, debes crear una política de certificación. Las afirmaciones de una entidad de autenticación deben coincidir con tu política para poder acceder a tus datos.

Las políticas se escriben en Common Expression Language (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 carga de trabajo o la instancia de VM como variables, y el valor especificado como la expresión. Por ejemplo, esta es una política que exige que la carga de trabajo use Confidential Space, debe usar una STABLE imagen de Confidential Space y que la zona en la que se ejecuta la instancia de VM de 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 afirmaciones de certificación para obtener más información.

Aserciones de certificación

En la siguiente tabla, se detallan las aserciones disponibles para construir una política de certificación. 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.

Aserciones de 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 los siguientes:

  • enable: Verifica que se esté usando la imagen de depuración.
  • disabled-since-boot: Verifica 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 Confidential Space:

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 string

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

Existen tres atributos de asistencia:

  • LATEST: Esta es la versión más reciente de la imagen y es compatible. La imagen LATEST también es STABLE y USABLE.
  • STABLE: Esta versión de la imagen es compatible y se supervisa para detectar vulnerabilidades. Una imagen STABLE también es USABLE.
  • USABLE: Una imagen con solo este atributo está fuera de asistencia y ya no se supervisa para detectar vulnerabilidades. Úsala bajo tu propia responsabilidad.
  • EXPERIMENTAL: Una imagen con solo este atributo utiliza funciones de vista previa. Solo se debe usar con fines de prueba y nunca en producción. Una imagen de 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 Confidential Space:

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

Verifica el software que se ejecuta en la entidad que certifica. El valor siempre es CONFIDENTIAL_SPACE.

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

Verifica la versión de software de la imagen de Confidential Space. Te recomendamos que uses assertion.submods.confidential_space.support_attributes en su lugar para segmentar la versión más reciente de una imagen.

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

Aserciones de contenedores

Aserción Tipo Descripción

assertion.submods.container.cmd_override

Interactúa con:

  • Autor de la carga de trabajo: La política de lanzamiento de allow_cmd_override .
  • Operador de carga de trabajo: Es la variable de metadatos tee-cmd .
 Matriz de string

Verifica los comandos y parámetros de CMD que se usan en la imagen de la carga de trabajo.

Ejemplos

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

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

El siguiente código verifica que program sea el único contenido en 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 pasado de forma explícita al contenedor.

Ejemplo

El siguiente código verifica que la variable de entorno example-env-1 esté configurada como value-1 y example-env-2 esté configurada 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:

 String

Verifica si el operador de carga de trabajo reemplazó las variables de entorno en el contenedor.

Ejemplos

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

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

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

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

Verifica el resumen de la imagen del contenedor de la carga de trabajo. Especificar esta condición permite que varias partes acuerden una carga de trabajo autorizada que pueda acceder a sus datos.

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

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:

 String

Verifica la ubicación del contenedor de carga de trabajo que se ejecuta sobre 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. Especificar esta condición permite que varias partes acuerden una carga de trabajo autorizada que pueda acceder a sus datos.

La aserción puede incluir los siguientes elementos:

  • key_id: Es la 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

    Aquí, public_key.pem es tu clave pública en formato PEM.

  • signature: Es la firma de una carga útil asociada con el contenedor firmado y que sigue el formato de firma simple.

  • signature_algorithm: Es el algoritmo que se usa para firmar la clave. Uno de los siguientes:

    • RSASSA_PSS_SHA256 (RSASSA-PSS con un resumen SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 con un resumen SHA-256)
    • ECDSA_P256_SHA256 (ECDSA en la curva P-256 con un resumen 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 iniciador de contenedores cuando se detiene la carga de trabajo.

Los valores válidos son los siguientes:

  • Never (predeterminada)
  • 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 string

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

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

Verifica la tecnología subyacente de Confidential Computing. Las plataformas compatibles 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 supervisión en la entidad certificadora.

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

Verifica el ID de la instancia de VM.

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

Verifica el nombre de la instancia de VM.

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

Verifica que la VM ejecute un proyecto Google Cloud con el ID del proyecto especificado.

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

Verifica que la VM se ejecute en un proyecto Google Cloud 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: Es el valor de --zone .
 String

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 Confidential Computing de NVIDIA. Los valores válidos son los siguientes:

  • OFF: Ninguna de las funciones de Confidential Computing de NVIDIA está activa.
  • ON: El hardware, el firmware y el software de la GPU NVIDIA H100 activaron por completo las funciones de procesamiento confidencial.
  • DEVTOOLS: La GPU está en un modo de procesamiento 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"