Codelab sull'immagine container firmata

1. Panoramica

Questo codelab si basa sul codelab Confidential Space. Supporto delle immagini container firmate con un'opzione per autenticare un container utilizzando una chiave pubblica attestata anziché specificare il digest dell'immagine nella policy del pool di identità del workload (WIP).

Cosa è cambiato con il supporto delle immagini container firmate in Confidential Space:

Usabilità migliorata:con l'introduzione della funzionalità di firma delle immagini container, ora possiamo passare da un approccio basato sul digest delle immagini dei workload a un approccio basato sulla firma dei container per i collaboratori/revisori che autorizzano un'immagine.

Quando utilizzano direttamente i digest delle immagini, i proprietari delle risorse devono aggiornare le proprie norme con un digest delle immagini ogni volta che autorizzano una nuova immagine. Utilizzando le firme delle immagini, la policy contiene un'impronta della chiave pubblica, la cui chiave privata corrispondente è di proprietà del collaboratore/revisore e viene utilizzata per firmare le immagini sottoposte a revisione.
Per alcuni modelli di sicurezza, fare riferimento a una chiave di firma dell'immagine attendibile è più comodo rispetto all'aggiornamento di un elenco di nuovi valori digest dell'immagine.

Nessuna regressione della sicurezza:questo approccio alla firma del container non comporta alcuna regressione della sicurezza rispetto al precedente approccio al digest dell'immagine perché i limiti di attendibilità rimangono invariati. Nell'approccio alla firma del container, il proprietario della risorsa autorizza una chiave di verifica specificando l'impronta della chiave pubblica attendibile nel criterio WIP e il controllo dell'autorizzazione viene eseguito dal servizio di verifica dell'attestazione e da WIP. Il servizio di verifica dell'attestazione verifica che la firma sia associata al workload in esecuzione e il criterio WIP controlla che la chiave pubblica dichiarata dal servizio sia autorizzata dal criterio.

Sicurezza avanzata:l'utilizzo delle firme delle immagini container consente di delegare una certa quantità di attendibilità al firmatario dell'immagine. Se specifichi l'impronta della chiave pubblica di un firmatario attendibile nella policy di attestazione, il proprietario della risorsa autorizza il firmatario a rilasciare approvazioni in base alle quali le immagini container soddisfano una policy. Il servizio di verifica dell'attestazione verifica che la firma sia associata al workload in esecuzione e il criterio controlla che la chiave pubblica che ha creato la firma sia autorizzata dal criterio. In questo modo, il livello aggiuntivo di indirezione fornito dalla firma delle immagini mantiene le solide garanzie di sicurezza di Confidential Space.

L'unica differenza tra questi approcci è che il secondo utilizza un livello aggiuntivo di indirezione in cui le immagini dei workload vengono autorizzate con una chiave di firma. Ciò non introduce nuove vulnerabilità di sicurezza perché i limiti di attendibilità rimangono invariati.

Cosa imparerai a fare

In questo codelab imparerai a utilizzare una firma dell'immagine container per autorizzare l'accesso alle risorse protette:

Come firmare un'immagine container sottoposta ad audit utilizzando cosign
Come caricare le firme delle immagini container nei registry OCI per il rilevamento e l'archiviazione delle firme
Come configurare le risorse cloud necessarie per eseguire Confidential Space
Come eseguire il workload in uno spazio confidenziale con il supporto dell'immagine container firmata

Questo codelab mostra come utilizzare Confidential Space per l'attestazione remota di un'immagine container firmata da una chiave attendibile in esecuzione su Google Compute Engine.

Che cosa ti serve

Completa il codelab Confidential Space.
Un progetto Google Cloud
Un browser, ad esempio Chrome o Firefox
Familiarità con gli editor di testo standard di Linux, ad esempio Vim, Emacs o Nano
Conoscenza di base di Sigstore cosign
Conoscenza di base di Google Compute Engine ( codelab), Confidential VM, container e repository remoti
Conoscenza di base di Cloud KMS ( codelab)
Conoscenza di base di service account, federazione delle identità per i carichi di lavoro e condizioni degli attributi.
Conoscenza di base di Artifact Registry
Conoscenza di base delle firme digitali

Ruoli coinvolti in uno spazio confidenziale con immagine container firmata

In questo codelab, Primus Bank sarà l'auditor e il proprietario della risorsa, responsabile di quanto segue:

Configurazione delle risorse richieste con dati di esempio.
Controllo del codice del workload.
Utilizzo di cosign per firmare l'immagine del workload.
Caricamento della firma in un repository.
Configurazione della policy WIP per proteggere i dati dei clienti.

Secundus Bank sarà l'autore e l'operatore del carico di lavoro e sarà responsabile di:

Configurazione delle risorse richieste per archiviare il risultato.
Scrittura del codice del carico di lavoro.
Pubblicazione dell'immagine del carico di lavoro.
Esecuzione del carico di lavoro in Confidential Space con supporto per le immagini container firmate.

La banca Secundus svilupperà e pubblicherà un workload che eseguirà query sui dati dei clienti archiviati in un bucket Cloud Storage e di proprietà della banca Primus. Primus Bank eseguirà l'audit del workload, firmerà l'immagine container e configurerà i criteri WIP per consentire l'accesso ai propri dati da parte dei workload approvati. Il risultato di questa esecuzione del workload verrà archiviato in un bucket Cloud Storage di proprietà della banca Secundus.

Risorse coinvolte nella configurazione di uno spazio confidenziale

Questo codelab fa riferimento a una serie di variabili che devi impostare sui valori appropriati per il tuo progetto Google Cloud. I comandi di questo codelab presuppongono che queste variabili siano state impostate. (ad esempio, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' può essere utilizzato per impostare il nome del bucket di archiviazione di input della banca Primus). Se le variabili dei nomi delle risorse non sono state impostate, verranno generate in base all'ID progetto GCP.

Configura quanto segue nel progetto Primus:

$PRIMUS_INPUT_STORAGE_BUCKET: il bucket che archivia il file di dati del cliente.
$PRIMUS_WORKLOAD_IDENTITY_POOL: il pool di identità del workload (WIP) che convalida le rivendicazioni.
$PRIMUS_WIP_PROVIDER: il fornitore di pool di identità del workload che include la condizione di autorizzazione da utilizzare per i token firmati dal servizio di verifica dell'attestazione.
$PRIMUS_SERVICEACCOUNT: il service account utilizzato da $PRIMUS_WORKLOAD_IDENTITY_POOL per accedere alle risorse protette. In questo passaggio ha l'autorizzazione per visualizzare i dati dei clienti archiviati nel bucket $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY: la chiave KMS utilizzata per criptare i dati archiviati in $PRIMUS_INPUT_STORAGE_BUCKET.

Risorse nuove in questo codelab:

$PRIMUS_COSIGN_REPOSITORY: Artifact Registry per archiviare le firme delle immagini del workload.
$PRIMUS_SIGNING_KEY: la chiave KMS utilizzata per firmare l'immagine del workload da parte dell'auditor/collaboratore dei dati (ad es.Primus Bank in questo caso).

Configura quanto segue nel progetto Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: il registro degli artefatti in cui verrà eseguito il push dell'immagine Docker del workload.
$WORKLOAD_IMAGE_NAME: il nome dell'immagine Docker del workload.
$WORKLOAD_IMAGE_TAG: il tag dell'immagine Docker del workload.
$WORKLOAD_SERVICEACCOUNT: il service account che dispone dell'autorizzazione per accedere alla VM confidenziale che esegue il workload.
$SECUNDUS_RESULT_BUCKET: il bucket che archivia i risultati del workload.

Altre risorse:

primus_customer_list.csv contiene i dati dei clienti. Caricheremo questi dati su $PRIMUS_INPUT_STORAGE_BUCKET e creeremo un workload che li interrogherà.

Workflow esistente

Quando esegui il carico di lavoro in Confidential Space, viene eseguito il seguente processo utilizzando le risorse configurate:

Il workload richiede un token di accesso Google generale per $PRIMUS_SERVICEACCOUNT dal WIP. Offre un token di servizio di verifica dell'attestazione con attestazioni di workload e ambiente.
Se le attestazioni di misurazione del carico di lavoro nel token di servizio Attestation Verifier corrispondono alla condizione dell'attributo nel WIP, viene restituito il token di accesso per $PRIMUS_SERVICEACCOUNT.
Il carico di lavoro utilizza il token di accesso dell'account di servizio associato a $PRIMUS_SERVICEACCOUNT per accedere ai dati del cliente nel bucket $PRIMUS_INPUT_STORAGE_BUCKET.
Il carico di lavoro esegue un'operazione su questi dati.
Il workload utilizza il service account $WORKLOAD_SERVICEACCOUNT per scrivere i risultati dell'operazione nel bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

Nuovo flusso di lavoro con supporto dei container firmati

Il supporto dei contenitori firmati verrà integrato nel flusso di lavoro esistente, come evidenziato di seguito. Quando esegui il workload in Confidential Space con il supporto delle immagini container firmate, viene eseguito il seguente processo utilizzando le risorse configurate:

Confidential Space rileva eventuali firme dei container correlate all'immagine del carico di lavoro in esecuzione e le invia al verificatore dell'attestazione. Il verificatore dell'attestazione verifica la firma e include eventuali firme valide nelle attestazioni.
Il workload richiede un token di accesso Google generale per $PRIMUS_SERVICEACCOUNT dal WIP. Offre un token di servizio di verifica dell'attestazione con attestazioni di workload e ambiente.
Se le rivendicazioni della firma del contenitore nel token del servizio di verifica dell'attestazione corrispondono alla condizione dell'attributo nel WIP, viene restituito il token di accesso per $PRIMUS_SERVICEACCOUNT.
Il carico di lavoro utilizza il token di accesso dell'account di servizio associato a $PRIMUS_SERVICEACCOUNT per accedere ai dati del cliente nel bucket $PRIMUS_INPUT_STORAGE_BUCKET.
Il carico di lavoro esegue un'operazione su questi dati.
Il workload utilizza $WORKLOAD_SERVICEACCOUNT per scrivere i risultati dell'operazione nel bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configurare le risorse cloud

Nell'ambito della configurazione di Confidential Space, per prima cosa creerai le risorse cloud richieste nei progetti GCP delle banche Primus e Secundus. Queste sono le risorse nuove di questo codelab:

Nel progetto Primus:

Chiave di firma KMS utilizzata per firmare i carichi di lavoro Secundus dopo l'audit del codice.
Repository Artifact Registry per archiviare le firme Cosign.

Non ci sono nuove risorse nel progetto Secundus. Una volta configurate queste risorse, creerai un service account per il workload con i ruoli e le autorizzazioni richiesti. A questo punto, creerai un'immagine del workload e l'auditor, la banca Primus, la firmerà. Il carico di lavoro verrà quindi autorizzato dai collaboratori dei dati (Primus Bank in questo codelab) e l'operatore del carico di lavoro (Secundus Bank in questo caso) eseguirà il carico di lavoro.

Nell'ambito della configurazione di Confidential Space, creerai le risorse cloud richieste nei progetti Google Cloud Primus e Secundus.

Prima di iniziare

Clona questo repository utilizzando il comando riportato di seguito per ottenere gli script richiesti utilizzati in questo codelab.

git clone https://github.com/GoogleCloudPlatform/confidential-space

Cambia la directory per questo codelab.

cd confidential-space/codelabs/signed_container_codelab/scripts

Assicurati di aver impostato i progetti richiesti come mostrato di seguito.

export PRIMUS_PROJECT_ID=<GCP project id of primus bank>
export SECUNDUS_PROJECT_ID=<GCP project id of secundus bank>

Imposta le variabili per i nomi delle risorse menzionati in precedenza utilizzando questo comando. Puoi eseguire l'override dei nomi delle risorse utilizzando queste variabili (ad es.export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket')
Esegui il seguente script per impostare i nomi delle variabili rimanenti su valori basati sull'ID progetto per i nomi delle risorse.

source config_env.sh

Installa cosign seguendo le istruzioni riportate qui.

Configurare le risorse della banca Primus

Nell'ambito di questo passaggio, configurerai le risorse cloud richieste per la banca Primus. Esegui il seguente script per configurare le risorse per la banca Primus. Nell'ambito di questi passaggi, verranno create le risorse menzionate di seguito:

Bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) per archiviare il file di dati dei clienti criptato della banca Primus.
Chiave di crittografia ($PRIMUS_ENC_KEY) e portachiavi ($PRIMUS_ENC_KEYRING) in KMS per criptare il file di dati della banca Primus.
Pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL) per convalidare le attestazioni in base alle condizioni degli attributi configurate nel relativo fornitore.
Service account ($PRIMUS_SERVICEACCOUNT) collegato al pool di identità del workload menzionato sopra ($PRIMUS_WORKLOAD_IDENTITY_POOL) con il seguente accesso IAM:
roles/cloudkms.cryptoKeyDecrypter per decriptare i dati utilizzando la chiave KMS.
objectViewer per leggere i dati dal bucket Cloud Storage.
roles/iam.workloadIdentityUser per connettere questo service account al pool di identità del workload.

./setup_primus_bank_resources.sh

Configurare le risorse della banca Secundus

Nell'ambito di questo passaggio, configurerai le risorse cloud richieste per la banca Secundus. Esegui il seguente script per configurare le risorse per la banca Secundus. Nell'ambito di questi passaggi, verranno create le risorse menzionate di seguito:

Bucket Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) per archiviare il risultato dell'esecuzione del carico di lavoro da parte della banca Secundus.

./setup_secundus_bank_resources.sh

3. Crea e firma il workload

Crea un service account del workload

Ora creerai un service account per il workload con i ruoli e le autorizzazioni richiesti. Esegui il seguente script per creare un service account del workload nel progetto della banca Secundus. Questo service account verrà utilizzato dalla VM che esegue il workload.

Questo service account del workload ($WORKLOAD_SERVICEACCOUNT) avrà i seguenti ruoli:
confidentialcomputing.workloadUser per ottenere un token di attestazione
logging.logWriter per scrivere i log in Cloud Logging.
objectViewer per leggere i dati dal bucket di archiviazione cloud $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin per scrivere il risultato del workload nel bucket Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.

./create_workload_serviceaccount.sh

Crea workload

Nell'ambito di questo passaggio, creerai un'immagine Docker del workload. Il carico di lavoro utilizzato in questo codelab è una semplice app Go basata sulla CLI che conta i clienti (dai dati dei clienti della banca Primus) da una posizione geografica fornita come argomento. Esegui il seguente script per creare un carico di lavoro in cui vengono eseguiti i seguenti passaggi:

Crea Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) di proprietà della banca Secundus.
Aggiorna il codice del workload con i nomi delle risorse richieste. Qui trovi il codice del workload utilizzato per questo codelab.
Crea il binario Go e il Dockerfile per creare un'immagine Docker del codice del workload. Qui trovi il Dockerfile utilizzato per questo codelab.
Crea e pubblica l'immagine Docker in Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) di proprietà della banca Secundus.
Concedi l'autorizzazione di lettura $WORKLOAD_SERVICEACCOUNT per $SECUNDUS_ARTIFACT_REGISTRY. È necessario che il container del workload esegua il pull dell'immagine Docker del workload da Artifact Registry.

./create_workload.sh

Firma del workload

Utilizzeremo Cosign per firmare l'immagine del workload. Per impostazione predefinita, Cosign memorizza le firme nello stesso repository dell'immagine che sta firmando. Per specificare un repository diverso per le firme, puoi impostare la variabile di ambiente COSIGN_REPOSITORY.

Qui utilizzeremo Artifact Registry come esempio. Puoi anche scegliere altri registri basati su OCI come Docker Hub e AWS CodeArtifact in base alle tue preferenze.

Crea un repository Docker Artifact Registry.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}

Crea un keyring e una chiave in KMS per firmare un'immagine del workload.

gcloud config set project $PRIMUS_PROJECT_ID

gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=${PRIMUS_PROJECT_LOCATION}

gcloud kms keys create $PRIMUS_SIGNING_KEY \
  --keyring=$PRIMUS_SIGNING_KEYRING \
  --purpose=asymmetric-signing \
  --default-algorithm=ec-sign-p256-sha256 \
  --location=${PRIMUS_PROJECT_LOCATION}

Per Artifact Registry, è previsto un nome completo dell'immagine, ad esempio $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME. Puoi caricare qualsiasi immagine container nel repository per l'archiviazione delle firme.

export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo

Concedi il ruolo Visualizzatore nel repository $PRIMUS_COSIGN_REPOSITORY all'account di servizio $WORKLOAD_SERVICEACCOUNT. In questo modo Confidential Space può rilevare eventuali firme di immagini container caricate in $PRIMUS_COSIGN_REPOSITORY.

gcloud artifacts repositories add-iam-policy-binding ${PRIMUS_COSIGN_REPOSITORY} \
--project=${PRIMUS_PROJECT_ID} --role='roles/viewer' --location=us \
--member="serviceAccount:${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com"

Cosign è uno strumento potente con più funzionalità di firma. Per il nostro caso d'uso, richiediamo solo a Cosign di firmare con una coppia di chiavi. La firma senza chiave congiunta non è supportata per questa funzionalità di immagine container firmata.

Quando si firma con una coppia di chiavi, esistono due opzioni:

Firma con una coppia di chiavi locale generata da Cosign.
Firma con una coppia di chiavi archiviata altrove (ad esempio in un KMS).

Genera una coppia di chiavi in Cosign se non ne hai una. Per ulteriori dettagli, consulta la sezione Firma con chiavi autogestite. Qui abbiamo specificato entrambi i modi (localmente e utilizzando il provider KMS) per generare la coppia di chiavi e firmare il workload. Segui uno di questi modi per firmare il contenitore del workload.

// Set Application Default Credentials.
gcloud auth application-default login

// Generate keys using a KMS provider.
cosign generate-key-pair --kms <provider>://<key>

// Generate keys using Cosign.
cosign generate-key-pair

Nell'esempio precedente, sostituisci <provider>://<key> con gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION

<provider> : si riferisce alla soluzione KMS che stai utilizzando
<key> : si riferisce al percorso della chiave in KMS

Recupera la chiave pubblica per la verifica.

// For KMS providers.
cosign public-key --key <some provider>://<some key> > pub.pem

// For local key pair signing.
cosign public-key --key cosign.key > pub.pem

Firma il workload utilizzando Cosign. Esegui la codifica Base64 senza padding sulla chiave pubblica

PUB=$(cat pub.pem | openssl base64)

// Remove spaces and trailing "=" signs.
PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')

Firma il workload utilizzando Cosign con gli algoritmi di firma e la chiave pubblica esportata allegati.

IMAGE_REFERENCE=us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/$SECUNDUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG

// Sign with KMS support.
cosign sign --key <some provider>://<some key> $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

// Sign with a local key pair.
cosign sign --key cosign.key $IMAGE_REFERENCE \
-a dev.cosignproject.cosign/sigalg=ECDSA_P256_SHA256 \
-a dev.cosignproject.cosign/pub=$PUB

--key [OBBLIGATORIO] specifica la chiave di firma da utilizzare. Quando fai riferimento a una chiave gestita da un provider KMS, segui il formato URI specifico di Supporto di Sigstore KMS. Quando fai riferimento a una chiave generata da Cosign, utilizza cosign.key.
$IMAGE_REFERENCE [OBBLIGATORIO] specifica l'immagine container da firmare. Il formato di IMAGE_REFERENCE può essere identificato tramite tag o digest dell'immagine. Ad esempio: us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container:latest or us-docker.pkg.dev/$SECUNDUS_PROJECT_ID/secundus-workloads/workload-container[IMAGE-digest]
- [REQUIRED] specifica le annotazioni allegate al payload della firma. Per le immagini container firmate di Confidential Space, è necessario allegare al payload della firma gli algoritmi di firma e la chiave pubblica.

dev.cosignproject.cosign/sigalg ONLY accetta tre valori:
RSASSA_PSS_SHA256: algoritmo RSASSA con padding PSS con un digest SHA256.
RSASSA_PKCS1V15_SHA256: algoritmo RSASSA con riempimento PKCS#1 v1.5 con un digest SHA256.
ECDSA_P256_SHA256: ECDSA sulla curva P-256 con un digest SHA256. Questo è anche l'algoritmo di firma predefinito per le coppie di chiavi generate da Cosign.

Caricare le firme nel repository Docker

Cosign sign caricherà automaticamente le firme nel COSIGN_REPOSITORY. specificato

4. Autorizza ed esegui il workload

Autorizza workload

Nell'ambito di questo passaggio, configureremo il fornitore di identità del workload nel pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL). Per l'identità del workload sono configurate condizioni degli attributi, come mostrato di seguito. Una delle condizioni è convalidare l'impronta della firma dell'immagine del carico di lavoro rispetto all'impronta della chiave pubblica di firma. Con questa condizione dell'attributo, quando Secundus Bank rilascia una nuova immagine del workload, Primus Bank esegue l'audit del codice del workload e firma la nuova immagine del workload senza dover aggiornare il criterio WIP con il digest dell'immagine.

gcloud config set project $PRIMUS_PROJECT_ID

PUBLIC_KEY_FINGERPRINT=$(openssl pkey -pubin -in pub.pem -outform DER | openssl sha256 | cut -d' ' -f2)

gcloud iam workload-identity-pools providers create-oidc ${PRIMUS_WIP_PROVIDER} \
   --location="global" \
   --workload-identity-pool="${PRIMUS_WORKLOAD_IDENTITY_POOL}" \
   --issuer-uri="https://confidentialcomputing.googleapis.com/" \
   --allowed-audiences="https://sts.googleapis.com" \
   --attribute-mapping="google.subject='assertion.sub'" \
   --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' &&
  'STABLE' in assertion.submods.confidential_space.support_attributes
     && '${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com' in
     assertion.google_service_accounts
     && ['ECDSA_P256_SHA256:${PUBLIC_KEY_FINGERPRINT}']
       .exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig,sig.signature_algorithm+':'+sig.key_id))"

Esegui workload

Nell'ambito di questo passaggio, eseguiremo il carico di lavoro su Confidential VM. Gli argomenti TEE obbligatori vengono passati utilizzando il flag dei metadati. Gli argomenti per il container del workload vengono passati utilizzando la parte "tee-cmd" del flag. Il workload è codificato per pubblicare il risultato su $SECUNDUS_RESULT_STORAGE_BUCKET.

gcloud compute instances create ${WORKLOAD_VM} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --project=${SECUNDUS_PROJECT_ID} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
 --service-account=${WORKLOAD_SERVICEACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=us-docker.pkg.dev/${SECUNDUS_PROJECT_ID}/${SECUNDUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]"~tee-signed-image-repos=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo"

Visualizza risultati

Nel progetto Secundus, visualizza i risultati del workload.

gcloud config set project $SECUNDUS_PROJECT_ID

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

Il risultato dovrebbe essere 3, poiché questo è il numero di persone di Seattle elencate nel file primus_customer_list.csv.

5. Esegui la pulizia

Qui trovi lo script che può essere utilizzato per pulire le risorse che abbiamo creato nell'ambito di questo codelab. Nell'ambito di questa pulizia, verranno eliminate le seguenti risorse:

Bucket di archiviazione di input della banca Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Service account della banca Primus ($PRIMUS_SERVICEACCOUNT).
Registro degli artefatti di Primus Bank che contiene le firme delle immagini ($PRIMUS_COSIGN_REPOSITORY).
Pool di identità del workload di Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Service account del workload di Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Istanza di computing del workload.
Bucket di archiviazione dei risultati di Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Artifact Registry di Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).
VM del workload di Secundus Bank ($WORKLOAD_VM).

./cleanup.sh

Se hai terminato l'esplorazione, valuta la possibilità di eliminare il progetto.

Vai alla console di Cloud Platform.
Seleziona il progetto che vuoi chiudere, quindi fai clic su "Elimina" in alto: il progetto verrà pianificato per l'eliminazione.

Complimenti

Congratulazioni, hai completato il codelab.

Hai imparato a sfruttare la funzionalità delle immagini container firmate per migliorare l'usabilità di Confidential Space.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab simili…