Crea e concedi l'accesso alle risorse riservate

Collaboratori ai dati

I collaboratori dei dati devono configurare le seguenti risorse per consentire l'accesso ai dati riservati da parte di un workload:

• Dati criptati, archiviati in Google Cloud.

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

Inoltre, i collaboratori dei dati devono scegliere dove archiviare i risultati del workload di Confidential Space e se questi risultati sono univoci per ogni collaboratore o condivisi. Ad esempio, puoi scegliere di inviare lo stesso risultato a più bucket Cloud Storage appartenenti a ciascun collaboratore ai dati.

Nota: Se le risorse del collaboratore di dati non sono gestite da Google CloudIAM, l'accesso a tali risorse può essere gestito richiedendo token di attestazione con destinatari personalizzati e nonce opzionali. Collabora con l'autore del workload per implementare questa soluzione. Per saperne di più, consulta Accedi alle risorse non gestite da Google Cloud IAM.

Archivia i dati criptati

Puoi utilizzare qualsiasi servizio Google Cloud che archivia i dati per ospitare i tuoi dati riservati. Ad esempio, puoi utilizzare uno dei seguenti servizi:

• BigQuery

• Cloud SQL

• Cloud Storage

• Filestore

• Persistent Disk

Assicurati che questi dati siano criptati at-rest, utilizzando le funzionalità integrate o con uno strumento come Cloud Key Management Service (Cloud KMS).

Attenzione: quando testi un workload sui dati, non utilizzare informazioni private. Configura dati fittizi nello stesso formato ed esegui i test su questi dati finché non è tutto pronto per bloccare il workload.

Autorizza il workload con un WIP

Un WIP è il meccanismo utilizzato da Confidential Space per consentire a un workload esterno di accedere e utilizzare i tuoi dati riservati come identità federata. Un'identità federata è un'entità esterna che viene trattata come se fosse un'entità all'interno del tuo progetto, consentendoti di concederle ruoli IAM per dare accesso a risorse specifiche o di simulare l'identità dei 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 le entità che si autenticano 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 Confidential VM e, infine, restituisce un token di attestazione OpenID Connect (OIDC) al provider WIP. L'operatore del workload imposta il servizio di attestazione utilizzato, che deve corrispondere al servizio di attestazione aggiunto al provider WIP per concedere l'accesso.

• Mappature degli attributi: attributi nei token di accesso di Security Token Service mappati alle asserzioni effettuate dall'entità di autenticazione, in questo caso l'istanza VM che esegue il workload. Le asserzioni vengono effettuate 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 audit in Cloud Logging e per concedere ruoli tramite IAM in base alle asserzioni dell'entità di autenticazione, come i digest dei container delle immagini dei workload. Scopri di più sulle mappature degli attributi.

• Una policy 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, l'Avvio applicazioni di Confidential Space 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 passato al provider WIP dal workload e il provider lo utilizza per verificare che le asserzioni superino la policy di attestazione definita nel provider. In caso affermativo, il workload può accedere alle risorse riservate.

Nota: anziché utilizzare i server di Google per la convalida dei token, puoi convalidare autonomamente i token di attestazione con certificati a lungo termine.

Accesso al workload esterno

Prima di configurare un provider e un pool di identità per i workload, devi scegliere in che modo il workload accederà alle tue risorse: accesso diretto alle risorse o simulazione dell'identità dei account di servizio.

Accesso diretto alle risorse

Per i workload, consigliamo il metodo di accesso diretto alle risorse.

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 workload può essere autorizzato ad accedere alle risorse direttamente tramite le associazioni IAM, in base ad attributi come il digest dell'immagine container del workload.

L'accesso diretto alle risorse presenta i seguenti vantaggi:

• La configurazione di un ambiente Confidential Space richiede meno passaggi, poiché i collaboratori dei dati non devono configurare service account per consentire la simulazione dell'identità da parte di un service account del workload.

• Il workload può accedere solo a risorse specifiche, come stabilito da IAM. Questo metodo è più sicuro rispetto alla simulazione dell'identità dei account di servizio, in cui i service account con autorizzazioni eccessive o i diritti di simulazione dell'identità potrebbero fornire a un malintenzionato un accesso maggiore del 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 account 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 una traccia di audit più dettagliata.

• Non è necessario 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'errore di autenticazione del provider WIP.

Simulazione dell'identità dei service account

Il metodo di simulazione dell'identità dei account di servizio prevede che ogni collaboratore ai dati configuri un account di servizio per decriptare i propri dati privati e poi lo colleghi al proprio WIP. Inoltre, specificano il account di servizio del workload nel provider WIP, consentendo al account di servizio del workload di simulare l'identità dei service account dei collaboratori ai dati in modo da poter recuperare e utilizzare i loro dati riservati.

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

• Quando devi utilizzare le firme delle immagini come credenziali di autenticazione, poiché la sintassi utilizzata dalle firme non funziona con le mappature degli attributi.

• Quando accedi ad API che non supportano le identità federate.

Il metodo di simulazione dell'identità dei account di servizio potrebbe non riuscire ad autenticarsi con un provider WIP se un'istanza VM ha una proprietà selfLink molto lunga. Questo perché l'attestazione sub nel token di attestazione, che è impostata sul valore selfLink, è 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.

Configura un WIP e un provider

I passaggi per la configurazione di un provider cambiano a seconda che tu utilizzi l'accesso diretto alle risorse o la simulazione dell'identità dei account di servizio.

Accesso diretto alle risorse

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

Configura un WIP e un provider

Per configurare un WIP e un provider, 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="ISSUER_URI" \
       --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 che corrisponde al servizio di attestazione che stai utilizzando:

     • Google Cloud Attestation: https://confidentialcomputing.googleapis.com

     • Intel Trust Authority: https://portal.trustauthority.intel.com

   • allowed-audiences di https://sts.googleapis.com. Si tratta del Security Token Service 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 il 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 container del workload. Questo attributo è mappato in modo da poter concedere i ruoli IAM dell'identità federata in base a un digest dell'immagine specifico.

     Puoi mappare qualsiasi asserzione del workload disponibile, purché 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, quest'ultimo è autorizzato ad 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 Crea una policy 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 alla corrispondenza del digest del container dell'immagine del workload dell'identità con un valore previsto.

L'esempio seguente 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 simulazione dell'identità dei account di servizio prevede quanto segue:

1. Creare service account in ciascuno dei progetti dei collaboratori ai dati e concedere loro l'autorizzazione per decriptare i dati riservati.

2. Creazione di WIP in ciascuno dei progetti dei collaboratori ai dati, quindi collegamento del account di servizio appena creato di ciascun progetto al relativo WIP.

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

Configura i service account per decriptare i dati riservati

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

   gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME
   

   Concedi ai service account le autorizzazioni necessarie per decriptare i dati riservati. Ad esempio, potresti criptare i file riservati in Cloud Storage con Cloud KMS, quindi devi concedere al account di servizio l'autorizzazione per decriptare i 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
   

Configura un WIP e un provider

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

1. Crea il WIP:

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

2. Collega il account di servizio di cui verrà simulata l'identità 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 al suo interno in modo che possa impersonare il service account del collaboratore ai 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.

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

   • Un attribute-mapping di google.subject, con il valore assertion.sub. Si tratta di selfLink dell'istanza VM, come definito nella rivendicazione 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, quest'ultimo è autorizzato ad accedere alle risorse come identità federata:

     • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': verifica che il digest dell'immagine container del workload 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, quindi lo utilizza per simulare l'identità del account di servizio del collaboratore ai 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 Crea una policy di attestazione.

Crea una policy di attestazione

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

Le policy sono scritte in Common Expression Language (CEL) e sono costituite da una serie di istruzioni che possono essere concatenate con l'operatore &&.

Le istruzioni utilizzano le asserzioni dell'immagine Confidential Space, dell'immagine container del workload o dell'istanza VM come variabili e il valore specificato come espressione. Ad esempio, ecco una policy che impone che il workload utilizzi Confidential Space, che utilizzi un'immagine Confidential Space STABLE e che la zona in cui viene eseguita l'istanza VM del workload sia 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 Asserzioni di attestazione.

Asserzioni di attestazione

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

Asserzioni di immagini

Asserzione	Tipo	Descrizione
assertion.dbgstat Interazione con: Operatore workload: il valore --image-family.	Enumerazione	Verifica che l'immagine Confidential Space sia la versione di debug o di produzione. I valori validi sono i seguenti: enable: verifica che l'immagine di debug sia in uso. disabled-since-boot: verifica che l'immagine di produzione sia in uso. 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 Confidential Space di debug non hanno un attributo di supporto impostato. La tabella seguente descrive gli attributi di supporto presenti nelle immagini Confidential Space di produzione. Attributo di supporto Descrizione LATEST Le immagini LATEST hanno anche i seguenti attributi di supporto: STABLE USABLE Durata dell'immagine: circa un mese. In seguito, l'attributo di supporto LATEST viene rimosso. Questa è l'ultima versione dell'immagine Confidential Space ed è supportata e monitorata per rilevare eventuali vulnerabilità. Per i workload a lunga esecuzione, ti consigliamo di non specificare LATEST come parte della policy di attestazione. Questo perché l'immagine Confidential Space potrebbe essere aggiornata mentre il workload è in esecuzione, rendendo l'immagine Confidential Space che stai utilizzando non più LATEST e causando l'attestazione del workload al successivo aggiornamento del token predefinito di Confidential Space. STABLE Le immagini STABLE hanno anche i seguenti attributi di supporto: USABLE Durata dell'immagine: circa sei mesi. A partire dal 1° aprile 2027, l'attributo di supporto STABLE viene rimosso dopo la scadenza della durata dell'immagine. Le immagini con l'attributo STABLE sono supportate e monitorate per rilevare eventuali vulnerabilità per un periodo di sei mesi. Ti consigliamo di scrivere una policy di attestazione basata sull'attributo STABLE. In rari casi, l'attributo STABLE può essere rimosso durante il normale periodo di assistenza di sei mesi, ad esempio quando vengono scoperte vulnerabilità critiche. USABLE Le immagini con solo l'attributo USABLE sono ancora disponibili per l'utilizzo, ma sono considerate deprecate. Le immagini deprecate non sono supportate e hanno più di sei mesi. Utilizzale a tuo rischio. Le immagini USABLE hanno una proprietà deprecated.deprecated. Il suo valore è il timestamp di quando è prevista la deprecazione dell'immagine. Le proprietà di un'immagine possono essere visualizzate con il comando gcloud compute images describe o con il metodo REST images.get. Ad esempio: gcloud compute images describe confidential-space-240800 \ --format=json \ --project=confidential-space-images EXPERIMENTAL Le immagini con solo questo attributo utilizzano le funzionalità di anteprima. Le immagini EXPERIMENTAL sono solo a scopo di test e non devono mai essere utilizzate in produzione. Un'immagine EXPERIMENTAL non ha mai gli attributi LATEST, STABLE o USABLE. Ti consigliamo di mantenere aggiornata l'immagine di Confidential Space. Per scoprire come aggiornare l'immagine di Confidential Space, consulta Aggiorna le immagini di Confidential Space. Importante: le immagini di Confidential Space possono essere revocate a causa di eventi come la scoperta di vulnerabilità critiche. Quando un'immagine viene revocata, la rivendicazione swname nel token di attestazione viene impostata su GCE oppure il tuo workload riceve un messaggio RIMS_VALIDATION_FAILED quando richiede il token. 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	Enumerazione	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

Asserzioni del container

Asserzione	Tipo	Descrizione
assertion.submods.container.cmd_override Interazione con: Autore del workload: la policy di lancio di allow_cmd_override. Operatore workload: la variabile dei metadati tee-cmd.	Array di stringhe	Verifica i comandi e i parametri CMD 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: Autore del workload: la policy di lancio di allow_env_override. Operatore del workload: la variabile dei metadati tee-env-ENVIRONMENT_VARIABLE_NAME .	Oggetto JSON	Verifica che le variabili di ambiente e i relativi valori siano stati passati esplicitamente al container. Esempio Il codice seguente verifica che la variabile di ambiente example-env-1 sia impostata su value-1 e che 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: Autore del workload: la policy di lancio di allow_env_override. Operatore workload: la variabile dei metadati tee-env-ENVIRONMENT_VARIABLE_NAME .	Stringa	Verifica se l'operatore del workload 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 workload 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 workload. La specifica di questa condizione consente a più parti di concordare un workload 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 workload. Esempio assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"
assertion.submods.container.image_reference Interazione con: Operatore workload: la variabile dei metadati tee-image-reference.	Stringa	Verifica la località del container del workload in esecuzione sull'immagine Confidential Space. Esempio assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"
assertion.submods.container.image_signatures Interazione con: Operatore workload: la variabile dei metadati tee-signed-image-repos.	Oggetto JSON	Verifica che l'immagine abbia una determinata firma o sia firmata da una chiave pubblica e da un algoritmo di firma. La specifica di questa condizione consente a più parti di concordare un workload autorizzato che può accedere ai loro dati. L'asserzione può includere i seguenti elementi: key_id: la fingerprint esadecimale della chiave pubblica. Per ottenere la fingerprint, puoi eseguire questo 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 container firmato e che segue il formato Simple Signing. 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 ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id))
assertion.submods.container.restart_policy Interazione con: Operatore workload: la variabile dei metadati tee-restart-policy.	Enumerazione	Verifica la policy di riavvio dell'utilità di avvio dei container per quando il workload si arresta. I valori validi sono i seguenti: Never (valore predefinito) Always OnFailure Esempio assertion.submods.container.restart_policy == "Never"

Asserzioni VM

Asserzione	Tipo	Descrizione
assertion.google_service_accounts Interazione con: Operatore del workload: la variabile dei metadati tee-impersonate-service-accounts e il valore --service-account .	Array di stringhe	Verifica che un account di servizio specificato sia connesso alla VM che esegue il workload o che sia stato elencato utilizzando tee-impersonate-service-accounts nei metadati della VM. Esempio [e-mail] in assertion.google_service_accounts
assertion.hwmodel	Stringa	Verifica la tecnologia di 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: Autore del workload: la policy di lancio di monitoring_memory_allow. Operatore workload: la variabile dei metadati tee-monitoring-memory-enable.	Booleano	Verifica lo stato del monitoraggio sull'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 progetto Google Cloud 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 Google Cloud con il numero di progetto specificato. Esempio assertion.submods.gce.project_number == "00000000000"
assertion.submods.gce.zone Interazione con: Operatore workload: 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_feature Interazione con: Operatore workload: la variabile dei metadati tee-install-gpu-driver.	Enumerazione	Verifica le funzionalità di Confidential Computing supportate da una GPU NVIDIA. In Confidential Space è supportata solo la modalità single GPU passthrough (SPT), pertanto il valore è sempre SPT. Per ulteriori informazioni sul supporto di NVIDIA Confidential Computing, consulta NVIDIA Trusted Computing Solutions (PDF). Esempio assertion.submods.nvidia_gpu.cc_feature == "SPT"
assertion.submods.nvidia_gpu.cc_mode Interazione con: Operatore workload: la variabile dei metadati tee-install-gpu-driver.	Enumerazione	Verifica lo stato del driver Confidential Computing di NVIDIA. I valori validi sono i seguenti: 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 una modalità Confidential Computing parziale che corrisponde ai flussi di lavoro della modalità ON, ma disabilita le protezioni di sicurezza. Esempio assertion.submods.nvidia_gpu.cc_mode == "ON"
assertion.submods.nvidia_gpu.gpus Interazione con: Operatore workload: la variabile dei metadati tee-install-gpu-driver.	Array di oggetti	Verifica le attestazioni per ogni GPU NVIDIA con attestazione. Confidential Space supporta una sola richiesta di GPU. Un oggetto gpus è simile al seguente: { "hwmodel": "GCP_NVIDIA_H100", "ueid": "490457405999046854973671575630853621547794591064", "l4_serial_number": "1216669666319372030078", "driver_version": "570.00", "vbios_version": "96.00.9F.00.01" } Esempi Il seguente codice verifica che il primo modello di hardware GPU sia un NVIDIA H100 in esecuzione su Google Cloud: assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100" Il seguente codice verifica che l'attestazione contenga claim relativi alla GPU: has(assertion.submods.nvidia_gpu.gpus)