Crea e concedi l'accesso alle risorse riservate

I collaboratori dei dati devono configurare le seguenti risorse per consentire a un workload di accedere ai dati riservati:

  • Dati criptati, archiviati in Google Cloud.

  • Un pool di identità del workload (WIP) per autorizzare il workload. Dopo che un carico di lavoro è stato autorizzato da un WIP, può accedere ai dati riservati dei collaboratori e utilizzarli.

Inoltre, i collaboratori dei dati devono scegliere dove vengono archiviati i risultati del carico di lavoro di Confidential Space e se questi risultati sono univoci per ogni collaboratore o condivisi. Ad esempio, potresti scegliere di restituire lo stesso risultato a più bucket Cloud Storage appartenenti a ogni collaboratore dei dati.

Memorizzare i dati criptati

Puoi utilizzare qualsiasi Google Cloud servizio che memorizza i dati per ospitare i tuoi dati confidenziali. Ad esempio, potresti utilizzare uno dei seguenti servizi:

Devi assicurarti che questi dati siano criptati at-rest, sia utilizzando funzionalità integrate sia con un servizio come Cloud Key Management Service (Cloud KMS).

Autorizza il workload con un WIP

Un WIP è il meccanismo che Confidential Space utilizza per consentire a un carico di lavoro esterno di accedere ai tuoi dati confidenziali e di utilizzarli come identità federata. Un'identità federata è un'entità esterna che viene trattata come se fosse un principal all'interno del tuo progetto, consentendoti di concedere ruoli IAM per dare accesso a risorse specifiche o per rappresentare service account per fare lo stesso.

In qualità di collaboratore dei dati, configuri un provider all'interno di un WIP che imposta le regole per l'autenticazione delle entità come identità federata. Per Confidential Space, devi definire quanto segue in un provider:

  • Un servizio di attestazione: questo servizio verifica che il workload sia un'istanza VM confidenziale e restituisce infine un token di attestazione OpenID Connect (OIDC) al provider WIP. L'operatore del workload imposta il servizio di attestazione utilizzato, che deve corrispondere a quello aggiunto al fornitore WIP per concedere l'accesso.

  • Mappature degli attributi: attributi nei token di accesso del servizio token di sicurezza che vengono mappati alle asserzioni effettuate dall'entità di autenticazione, in questo caso l'istanza VM che esegue il workload. Le asserzioni vengono eseguite dall'istanza VM stessa, dall'immagine Confidential Space e dal container del workload e vengono passate al provider WIP dal workload. Questi attributi vengono utilizzati per elementi come le tracce di controllo in Cloud Logging e per concedere ruoli tramite IAM in base alle asserzioni dell'entità di autenticazione, ad esempio i digest dei container delle immagini dei workload. Scopri di più sulle mappature degli attributi.

  • Un criterio di attestazione: una serie di condizioni che le entità di autenticazione devono superare per ottenere l'accesso, in base alle asserzioni che fanno.

Quando un workload viene avviato, Confidential Space Launcher invia il report di attestazione a un servizio di attestazione definito dall'operatore del workload, che verifica l'istanza Confidential VM e restituisce un token di attestazione OIDC. Questo token dura un'ora e viene aggiornato automaticamente.

Il token di attestazione viene quindi trasmesso al provider WIP dal carico di lavoro e il provider lo utilizza per verificare che le asserzioni superino il criterio di attestazione definito nel provider. In questo caso, il carico di lavoro può accedere alle risorse riservate.

Accesso al workload esterno

Prima di configurare un WIP e un fornitore, devi scegliere in che modo il carico di lavoro accederà alle tue risorse: accesso diretto alle risorse o rappresentazione dell'account di servizio.

Accesso diretto alle risorse

Consigliamo il metodo di accesso diretto alle risorse per i workload.

Questo metodo prevede la configurazione di un'identità federata in un provider WIP collegato alle asserzioni di un'entità di autenticazione. In questo modo, un carico di lavoro può essere autorizzato ad accedere alle risorse direttamente tramite i binding IAM, in base ad attributi come il digest dell'immagine container del carico di lavoro.

L'accesso diretto alle risorse presenta i seguenti vantaggi:

  • La configurazione di un ambiente Confidential Space richiede meno passaggi, in quanto i collaboratori dei dati non devono configurare service account da impersonare per un service account del workload.

  • Il workload può accedere solo a risorse specifiche come determinato da IAM. Questo metodo è più sicuro della rappresentazione del account di servizio, in cui service account con autorizzazioni eccessive o diritti di rappresentazione potrebbero fornire a un malintenzionato più accesso di quanto previsto.

  • Ogni accesso alle risorse viene registrato con l'identità federata di un'istanza VM del workload, anziché con l'identità di un account di servizio rappresentato che potrebbe essere condiviso da più workload. L'identità di un'istanza VM del workload può includere dettagli come il digest dell'immagine di un container, il numero di progetto da cui opera il workload e l'ID dell'istanza VM che esegue il workload, fornendo un audit trail più dettagliato.

  • Non devi mappare la proprietà dell'istanza VM selfLink all'attributo google.subject in un provider WIP. I valori selfLink molto lunghi possono superare il limite di 127 byte di questo attributo, causando l'autenticazione del fornitore WIP non riuscita.

Simulazione dell'identità dei service account

Il metodo di rappresentazione dell'account di servizio prevede che ogni collaboratore dei dati configuri un account di servizio per decriptare i propri dati privati e poi lo colleghi al proprio WIP. Specificano anche l'account di servizio del carico di lavoro nel proprio fornitore WIP, il che consente all'account di servizio del carico di lavoro di simulare l'identità degli account di servizio del collaboratore dei dati in modo da poter recuperare e utilizzare i loro dati riservati.

La simulazione dell'identità del service account deve essere utilizzata solo nei seguenti scenari:

Il metodo di rappresentazione del account di servizio potrebbe non riuscire a eseguire l'autenticazione in un provider WIP se un'istanza VM ha una proprietà selfLink molto lunga. Questo perché l'attestazione sub nel token di attestazione, impostata sul valore selfLink, viene mappata nel provider WIP all'attributo google.subject, che ha un limite di 127 byte.

Per i valori selfLink dell'istanza VM che superano i 127 byte, devi rinominare le istanze VM per abbreviare selfLink o utilizzare il metodo di accesso diretto alle risorse.

Configurare un WIP e un fornitore

I passaggi per configurare un fornitore variano a seconda che utilizzi l'accesso diretto alle risorse o la simulazione dell'identità delaccount di serviziot.

Accesso diretto alle risorse

Il metodo di accesso diretto alle risorse prevede la configurazione di un WIP e di un fornitore, quindi la configurazione dei ruoli IAM in base a un digest specifico dell'immagine container del carico di lavoro.

Configurare un WIP e un fornitore

Per configurare un WIP e un fornitore, completa le seguenti istruzioni:

  1. Crea il WIP:

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

  2. Crea un provider OIDC nel 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"

    Questo esempio utilizza i seguenti valori:

    • Un issuer-uri di https://confidentialcomputing.googleapis.com/, il che significa che Google Cloud Attestation viene utilizzato come servizio di attestazione.

    • Un allowed-audiences di https://sts.googleapis.com. Si tratta del servizio di token di sicurezza di Google, che scambia le credenziali con i token di accesso.

    • Un attribute-mapping di google.subject, con il seguente valore:

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

      Questo valore viene creato utilizzando Common Expression Language (CEL). I seguenti valori vengono assegnati all'attributo gcpcs e vengono visualizzati in Cloud Logging ogni volta che il workload accede alle risorse:

      • assertion.submods.container.image_digest: il digest dell'immagine container del workload.

      • assertion.submods.gce.project_number: Il numero di progetto dell'istanza VM.

      • assertion.submods.gce.instance_id: l'ID dell'istanza VM.

      Inoltre, attribute.image_digest è impostato su assertion.submods.container.image_digest, il digest dell'immagine del container del workload. Questo attributo è mappato in modo da poter concedere ruoli IAM all'identità federata in base a un digest dell'immagine specifico.

      Puoi mappare una qualsiasi delle asserzioni del carico di lavoro disponibili, a condizione che la lunghezza totale del valore google.subject sia inferiore a 127 byte.

    • I seguenti attribute-conditions, che formano una policy di attestazione. Se queste condizioni corrispondono alle asserzioni del workload, allora al workload è consentito accedere alle risorse riservate come identità federata:

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica che Confidential Space sia il software in esecuzione sulla VM, con tutte le sue garanzie di sicurezza integrate.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica che venga utilizzata l'immagine Confidential Space di produzione e che abbia l'STABLE attributo di supporto.

      Per altre condizioni degli attributi che puoi utilizzare, consulta Creare un criterio di attestazione.

Concedi i ruoli IAM dell'identità federata

Dopo aver creato un provider WIP, puoi concedere all'identità federata un ruolo IAM in base al fatto che il digest del container dell'immagine del carico di lavoro dell'identità corrisponda a un valore previsto.

Il seguente esempio mostra come concedere a un'identità federata la possibilità di decriptare una chiave Cloud Key Management Service specifica:

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

Simulazione dell'identità dei service account

Il metodo di rappresentazione del account di servizio prevede quanto segue:

  1. Creazione di service account in ciascuno dei progetti dei collaboratori dei dati e concessione dell'autorizzazione per decriptare i dati riservati.

  2. Creazione di WIP in ciascuno dei progetti dei collaboratori dei dati e poi allegare a ogni WIP l'account di servizio del progetto appena creato.

  3. Creazione di provider WIP in ogni WIP che specificano l'account di servizio del workload come account autorizzato a simulare l'identità degli account di servizio dei collaboratori dei dati.

Configurare i service account per decriptare i dati riservati

  1. Crea i service account nei progetti dei collaboratori dei dati:

    gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME

    Concedi ai service account le autorizzazioni necessarie per decriptare i dati confidenziali. Ad esempio, potresti criptare file riservati in Cloud Storage con Cloud KMS, quindi devi concedere alaccount di serviziont l'autorizzazione per decriptare questi dati:

    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

Configurare un WIP e un fornitore

Per configurare un WIP e un fornitore, completa le seguenti istruzioni in ogni progetto di collaboratore dei dati:

  1. Crea il WIP:

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

  2. Collega il account di servizio che verrà rappresentato al WIP, con il ruolo 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 provider OIDC nel WIP e definisci il service account del workload in modo che possa rappresentare il service account del collaboratore dei dati:

    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"

    Questo esempio utilizza i seguenti valori:

    • Un issuer-uri di https://confidentialcomputing.googleapis.com/, il che significa che Google Cloud Attestation viene utilizzato come servizio di attestazione.

    • Un allowed-audiences di https://sts.googleapis.com. Si tratta del servizio di token di sicurezza di Google, che scambia le credenziali con i token di accesso.

    • Un attribute-mapping di google.subject, con il valore assertion.sub. Si tratta dell'selfLink dell'istanza VM, come definito nell'attestazione sub nel token di attestazione.

      L'istanza VM selfLink viene visualizzata in Cloud Logging ogni volta che il workload accede alle risorse.

    • I seguenti attribute-conditions, che formano una policy di attestazione. Se queste condizioni corrispondono alle asserzioni del workload, allora al workload è consentito accedere alle risorse come identità federata:

      • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': Verifica che il digest dell'immagine del container del carico di lavoro corrisponda al valore previsto.

      • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: Verifica che il account di servizio collegato al workload corrisponda al account di servizio previsto e lo utilizza per rappresentare il account di servizio del collaboratore dei dati.

      • assertion.swname == 'CONFIDENTIAL_SPACE': verifica che Confidential Space sia il software in esecuzione sulla VM, con tutte le sue garanzie di sicurezza integrate.

      • 'STABLE' in assertion.submods.confidential_space.support_attributes: Verifica che venga utilizzata l'immagine Confidential Space di produzione e che abbia l'STABLE attributo di supporto.

      Per altre condizioni degli attributi che puoi utilizzare, consulta Creare un criterio di attestazione.

Crea una policy di attestazione

Durante la creazione di un WIP, devi creare una norma di attestazione. Le asserzioni di un'entità di autenticazione devono corrispondere ai tuoi criteri per poter accedere ai tuoi dati.

I criteri sono scritti in Common Expression Language (CEL) e sono costituiti da una serie di istruzioni che possono essere concatenate con l'operatore &&.

Le istruzioni utilizzano asserzioni dall'immagine Confidential Space, dall'immagine container del workload o dall'istanza VM come variabili e il valore specificato come espressione. Ad esempio, ecco una policy che impone che il workload utilizzi Confidential Space, deve utilizzare un'STABLEimmagine Confidential Space e che la zona in cui viene eseguita l'istanza VM del workload deve essere us-central1-a:

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

Per saperne di più, consulta le asserzioni di attestazione.

Asserzioni di attestazione

Le asserzioni disponibili per creare una policy di attestazione sono descritte in dettaglio nella tabella seguente. I criteri possono convalidare le asserzioni fatte dall'immagine Confidential Space, dal container del workload e dall'istanza VM.

Affermazioni relative alle immagini

Asserzione Tipo Descrizione

assertion.dbgstat

Interazione con:

 Stringa definita

Verifica che l'immagine di Confidential Space sia la versione di debug o di produzione.

I valori validi sono:

  • enable: verifica che venga utilizzata l'immagine di debug.
  • disabled-since-boot: verifica che venga utilizzata l'immagine di produzione.
Esempi

Il seguente codice verifica che venga utilizzata la versione di debug dell'immagine Confidential Space:

assertion.dbgstat == "enable"

Il seguente codice verifica che venga utilizzata la versione di produzione dell'immagine Confidential Space:

assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes Array di stringhe

Verifica che la versione di sicurezza del TEE sia un'immagine Confidential Space di produzione. Le immagini di debug di Confidential Space non hanno l'attributo di supporto impostato.

Esistono tre attributi di supporto:

  • LATEST: Questa è l'ultima versione dell'immagine ed è supportata. L'immagine LATEST è anche STABLE e USABLE.
  • STABLE: Questa versione dell'immagine è supportata e monitorata per rilevare vulnerabilità. Un'immagine STABLE è anche USABLE.
  • USABLE: Un'immagine con solo questo attributo non è più supportata e non viene più monitorata per rilevare vulnerabilità. Utilizzalo a tuo rischio.
  • EXPERIMENTAL: Un'immagine con solo questo attributo utilizza le funzionalità di anteprima. È destinato solo a scopi di test e non deve mai essere utilizzato in produzione. Un'immagine EXPERIMENTAL non ha mai gli attributi LATEST, STABLE o USABLE.
Esempio

Il seguente codice verifica che venga utilizzata una versione stabile dell'immagine di Confidential Space:

"STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname Stringa definita

Verifica il software in esecuzione sull'entità di attestazione. Il valore è sempre CONFIDENTIAL_SPACE.

Esempio
assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion Array di stringhe

Verifica la versione software dell'immagine Confidential Space. Ti consigliamo di utilizzare assertion.submods.confidential_space.support_attributes per scegliere come target l'ultima versione di un'immagine.

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

Assert di contenitore

Asserzione Tipo Descrizione

assertion.submods.container.cmd_override

Interazione con:

 Array di stringhe

Verifica i CMD comandi e parametri utilizzati nell'immagine del workload.

Esempi

Il seguente codice verifica che il CMD dell'immagine del workload non sia stato sovrascritto:

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

Il seguente codice verifica che program sia l'unico contenuto negli override CMD:

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

assertion.submods.container.env

Interazione con:

 Oggetto JSON

Verifica che le variabili di ambiente e i relativi valori siano stati passati esplicitamente al container.

Esempio

Il seguente codice verifica che la variabile di ambiente example-env-1 sia impostata su value-1 e example-env-2 sia impostata su value-2.

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

assertion.submods.container.env_override

Interazione con:

 Stringa

Verifica se l'operatore del carico di lavoro ha sovrascritto le variabili di ambiente nel container.

Esempi

Il codice seguente verifica che l'operatore del workload non abbia eseguito l'override della variabile di ambiente example:

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

Il codice seguente verifica che l'operatore del carico di lavoro non abbia sovrascritto alcuna variabile di ambiente:

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

Verifica il digest dell'immagine del container del carico di lavoro. La specifica di questa condizione consente a più parti di concordare un carico di lavoro autorizzato che può accedere ai loro dati.

Esempio
assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id Stringa

Verifica l'ID immagine del container del carico di lavoro.

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

assertion.submods.container.image_reference

Interazione con:

 Stringa

Verifica la posizione del container del workload in esecuzione sopra l'immagine di Confidential Space.

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

assertion.submods.container.image_signatures

Interazione con:

 Oggetto JSON

Verifica che l'immagine abbia una determinata firma o sia firmata da una chiave pubblica e un algoritmo di firma. La specifica di questa condizione consente a più parti di concordare un carico di lavoro autorizzato che può accedere ai loro dati.

L'asserzione può includere i seguenti elementi:

  • key_id: L'impronta esadecimale della chiave pubblica. Per ottenere l'impronta, puoi eseguire il seguente comando:

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

    Dove public_key.pem è la tua chiave pubblica in formato PEM.

  • signature: La firma su un payload associato al contenitore firmato e che segue il formato di firma semplice.

  • signature_algorithm: l'algoritmo utilizzato per firmare la chiave. Il valore sarà uno dei seguenti:

    • RSASSA_PSS_SHA256 (RSASSA-PSS con un digest SHA-256)
    • RSASSA_PKCS1V15_SHA256 (RSASSA-PKCS1 v1_5 con un digest SHA-256)
    • ECDSA_P256_SHA256 (ECDSA sulla curva P-256 con un digest SHA-256)
Esempio
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

Interazione con:

 Stringa definita

Verifica la policy di riavvio del launcher del container per quando il workload si arresta.

I valori validi sono:

  • Never (valore predefinito)
  • Always
  • OnFailure
Esempio
assertion.submods.container.restart_policy == "Never"

Asserzioni VM

Asserzione Tipo Descrizione

assertion.google_service_accounts

Interazione con:

 Array di stringhe

Verifica che un account di servizio specificato sia connesso alla VM che esegue il workload o sia stato elencato utilizzando tee-impersonate-service-accounts nei metadati della VM.

Esempio
workload-service-account@my-project.iam.gserviceaccount.com in assertion.google_service_accounts
assertion.hwmodel Stringa

Verifica la tecnologia Confidential Computing sottostante. Le piattaforme supportate sono le seguenti:

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

assertion.submods.confidential_space.monitoring_enabled

Interazione con:

 Booleano

Verifica lo stato di monitoraggio dell'entità di attestazione.

Esempio
assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id Stringa

Verifica l'ID istanza VM.

Esempio
assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name Stringa

Verifica il nome dell'istanza VM.

Esempio
assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id Stringa

Verifica che la VM esegua un Google Cloud progetto con l'ID progetto specificato.

Esempio
assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number Stringa

Verifica che la VM sia in esecuzione in un progetto con il numero di progetto specificato. Google Cloud

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

assertion.submods.gce.zone

Interazione con:

  • Operatore del carico di lavoro: il valore --zone .
 Stringa

Verifica che la VM sia in esecuzione nella zona specificata.

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

assertion.submods.nvidia_gpu.cc_mode

Interazione con:

 Stringa definita

Verifica lo stato del driver Confidential Computing di NVIDIA. I valori validi sono:

  • OFF: nessuna delle funzionalità di NVIDIA Confidential Computing è attiva.
  • ON: l'hardware, il firmware e il software NVIDIA H100 hanno attivato completamente le funzionalità di confidential computing.
  • DEVTOOLS: la GPU è in modalità di computing confidenziale parziale che corrisponde ai flussi di lavoro della modalità ON, ma disattiva le protezioni di sicurezza.
Esempio
assertion.submods.nvidia_gpu.cc_mode == "ON"