Questa pagina è stata tradotta dall'API Cloud Translation.

Codelab sull'immagine container firmata

1. Panoramica

Questo codelab si basa sul codelab Confidential Space. Il supporto delle immagini container firmate offre la possibilità di autenticare un container utilizzando una chiave pubblica attestata invece di specificare il digest dell'immagine nel criterio del pool di identità per i carichi di lavoro.

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

Maggiore usabilità: con l'introduzione della funzionalità delle immagini container firmate, ora possiamo passare da un approccio digest delle immagini dei carichi di lavoro a un approccio alla firma dei container per i collaboratori/revisori che autorizzano un'immagine.

Quando si utilizzano direttamente le sintesi delle immagini, i proprietari delle risorse devono aggiornare i criteri con un digest immagine ogni volta che autorizzano una nuova immagine. Utilizzando le firme per le immagini, il criterio contiene una fingerprint di chiave pubblica, la cui chiave privata corrispondente è di proprietà del collaboratore/revisore e viene utilizzata per firmare le immagini controllate.
Per alcuni modelli di sicurezza, fare riferimento a una chiave di firma di un'immagine attendibile è più conveniente che aggiornare un elenco di nuovi valori di digest delle immagini.

Nessuna regressione di sicurezza: questo approccio alla firma dei container non comporta alcuna regressione della sicurezza rispetto al precedente approccio digest delle immagini perché i confini di attendibilità rimangono gli stessi. 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 degli attestazioni e dal servizio di verifica degli attestazioni. Il servizio di verifica delle attestazioni verifica che la firma sia associata al carico di lavoro in esecuzione, mentre il criterio WIP controlla che la chiave pubblica dichiarata dal servizio sia autorizzata dal criterio.

Sicurezza elevata: l'utilizzo delle firme per le immagini container consente di delegare un certo livello di attendibilità al firmatario dell'immagine. Specificando l'impronta digitale della chiave pubblica di un firmatario attendibile nel criterio di attestazione, il proprietario della risorsa autorizza il firmatario a verificare quali immagini container soddisfano un criterio. Il servizio di verifica delle attestazioni verifica che la firma sia associata al carico di lavoro in esecuzione e il criterio controlla che la chiave pubblica che l'ha creata sia autorizzata dal criterio. Grazie a ciò, 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 quest'ultimo utilizza un ulteriore livello di orientamento indiretto in cui le immagini dei carichi di lavoro vengono autorizzate con una chiave di firma. Ciò non introduce nuove vulnerabilità di sicurezza perché i confini di attendibilità rimangono gli stessi.

Cosa imparerai a fare

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

Come firmare un'immagine container controllata utilizzando cosign
Come caricare le firme delle immagini container nei registri OCI per il rilevamento e l'archiviazione delle firme
Come configurare le risorse cloud necessarie per l'esecuzione di Confidential Space
Eseguire il carico di lavoro in uno spazio riservato con il supporto dell'immagine container firmata

Questo codelab ti mostra come utilizzare Confidential Space per attestare in remoto un'immagine container firmata da una chiave attendibile in esecuzione su Google Compute Engine.

Che cosa ti serve

Completa il codelab di 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 del cosign Sigstore
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 account di servizio, 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 riservato con immagine container firmata

In questo codelab, Primus Bank sarà il revisore e il proprietario della risorsa, che si occuperà di quanto segue:

Configurazione delle risorse richieste con dati di esempio.
Controllo del codice del carico di lavoro in corso.
Utilizzo di cosign per firmare l'immagine del carico di lavoro.
Caricamento della firma in un repository.
È in corso la configurazione del criterio 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 in corso.
Pubblicazione dell'immagine del carico di lavoro in corso.
Esecuzione del carico di lavoro in Confidential Space con il supporto delle immagini container firmate.

Secundus Bank svilupperà e pubblicherà un carico di lavoro che eseguirà query sui dati dei clienti archiviati in un bucket di archiviazione cloud e di proprietà di Primus Bank. Primus Bank controllerà il carico di lavoro, firmerà l'immagine container e configurerà i criteri in fase di elaborazione (WIP) per consentire l'accesso ai propri dati da parte di carichi di lavoro approvati. Il risultato dell'esecuzione di questo carico di lavoro verrà archiviato in un bucket Cloud Storage di proprietà della banca Secundus.

Risorse coinvolte nella configurazione di Confidential Space

Questo codelab fa riferimento a una serie di variabili che dovresti impostare con i valori appropriati per il tuo progetto Google Cloud. I comandi in 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 risorsa non sono state impostate, verranno generate in base all'ID progetto Google Cloud.

Configura quanto segue nel progetto Primus:

$PRIMUS_INPUT_STORAGE_BUCKET: il bucket in cui è archiviato il file di dati dei clienti.
$PRIMUS_WORKLOAD_IDENTITY_POOL: il pool di identità per i carichi di lavoro (in fase di elaborazione) che convalida le rivendicazioni.
$PRIMUS_WIP_PROVIDER: il provider del pool di identità per i carichi di lavoro che include la condizione di autorizzazione da utilizzare per i token firmati dal servizio Attestation Verifier.
$PRIMUS_SERVICEACCOUNT: l'account di servizio che $PRIMUS_WORKLOAD_IDENTITY_POOL utilizza 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 per questo codelab:

$PRIMUS_COSIGN_REPOSITORY: Artifact Registry per archiviare le firme delle immagini dei carichi di lavoro.
$PRIMUS_SIGNING_KEY: la chiave KMS utilizzata per firmare l'immagine del carico di lavoro dal revisore/collaboratori ai dati (ad es.primus bank in questo caso).

Configura quanto segue nel progetto Secundus:

$SECUNDUS_ARTIFACT_REGISTRY: l'Artifact Registry in cui verrà eseguito il push dell'immagine Docker dei carichi di lavoro.
$WORKLOAD_IMAGE_NAME: il nome dell'immagine Docker dei carichi di lavoro.
$WORKLOAD_IMAGE_TAG: il tag dell'immagine Docker dei carichi di lavoro.
$WORKLOAD_SERVICEACCOUNT: l'account di servizio che dispone dell'autorizzazione per accedere alla Confidential VM che esegue il carico di lavoro.
$SECUNDUS_RESULT_BUCKET: il bucket in cui sono archiviati i risultati del carico di lavoro.

Altre risorse:

primus_customer_list.csv contiene i dati dei clienti. Caricheremo questi dati su $PRIMUS_INPUT_STORAGE_BUCKET e creeremo un carico di lavoro per eseguire query su questi dati.

Flusso di lavoro esistente

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

Il carico di lavoro richiede un token di accesso Google generale per $PRIMUS_SERVICEACCOUNT al WIP. Offre un token di servizio Attestation Verifier con attestazioni sui carichi di lavoro e sull'ambiente.
Se le attestazioni relative alla misurazione del carico di lavoro nel token di servizio Attestation Verifier corrispondono alla condizione dell'attributo in fase di elaborazione, restituisce il token di accesso per $PRIMUS_SERVICEACCOUNT.
Il carico di lavoro utilizza il token di accesso all'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 sui dati.
Il carico di lavoro utilizza l'account di servizio $WORKLOAD_SERVICEACCOUNT per scrivere i risultati dell'operazione nel bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

Nuovo flusso di lavoro con supporto per container firmato

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

Spazio riservato rileva le firme dei container relative all'immagine del carico di lavoro attualmente in esecuzione e le invia allo strumento di verifica dell'attestazione. Lo strumento di verifica dell'attestazione verifica la firma e include tutte le firme valide nelle attestazioni.
Il carico di lavoro richiede un token di accesso Google generale per $PRIMUS_SERVICEACCOUNT al WIP. Offre un token di servizio Attestation Verifier con attestazioni sui carichi di lavoro e sull'ambiente.
Se le dichiarazioni della firma del container nel token di servizio Attestation Verifier corrispondono alla condizione dell'attributo in fase di elaborazione, restituisce il token di accesso per $PRIMUS_SERVICEACCOUNT.
Il carico di lavoro utilizza il token di accesso all'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 sui dati.
Il carico di lavoro utilizza $WORKLOAD_SERVICEACCOUNT per scrivere i risultati dell'operazione nel bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configura risorse cloud

Nell'ambito della configurazione di Confidential Space, creerai innanzitutto le risorse cloud necessarie nei progetti Google Cloud di Primus e Secundus bank. Queste sono le risorse che non conoscete in questo codelab:

Nel progetto Primus:

Chiave di firma KMS utilizzata per firmare i carichi di lavoro Secundus, dopo aver controllato il codice.
Repository di Artifact Registry per archiviare le firme di Cosign.

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

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

Prima di iniziare

Clona questo repository utilizzando il comando in basso per ottenere gli script richiesti utilizzati nell'ambito di questo codelab.

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

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 in base all'ID progetto per i nomi delle risorse.

$ source config_env.sh

Installa la firma condivisa seguendo le istruzioni riportate qui.

Configura le risorse della banca Primus

Nell'ambito di questo passaggio, configurerai le risorse cloud richieste per Primus bank. Esegui questo script per configurare le risorse per la banca Primus. Nell'ambito di questa procedura, verranno create le risorse menzionate di seguito:

Bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) per archiviare il file criptato dei dati dei clienti della banca Primus.
Chiave di crittografia ($PRIMUS_ENC_KEY) e keyring ($PRIMUS_ENC_KEYRING) nel KMS per criptare il file di dati della banca Primus.
Pool di identità per i carichi di lavoro ($PRIMUS_WORKLOAD_IDENTITY_POOL) per convalidare le attestazioni in base alle condizioni degli attributi configurate nel relativo provider.
Account di servizio ($PRIMUS_SERVICEACCOUNT) collegato al pool di identità per i carichi di lavoro ($PRIMUS_WORKLOAD_IDENTITY_POOL) sopra menzionato 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 la connessione di questo account di servizio al pool di identità per i carichi di lavoro.

$ ./setup_primus_bank_resources.sh

Configura le risorse della banca Secundus

Nell'ambito di questo passaggio, configurerai le risorse cloud richieste per Secundus bank. Esegui questo script per configurare le risorse per la banca Secundus. Nell'ambito di questa procedura, 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 carico di lavoro

Crea account di servizio per i carichi di lavoro

Ora creerai un account di servizio per il carico di lavoro con le autorizzazioni e i ruoli richiesti. Esegui il seguente script per creare un account di servizio per i carichi di lavoro nel progetto della banca Secundus. Questo account di servizio verrà utilizzato dalla VM che esegue il carico di lavoro.

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

$ ./create_workload_serviceaccount.sh

Crea carico di lavoro

Nell'ambito di questo passaggio, creerai un'immagine Docker del carico di lavoro. Il carico di lavoro utilizzato in questo codelab è una semplice app Go basata su interfaccia a riga di comando che conteggia i clienti (dai dati dei clienti della banca Primus) da una posizione geografica fornita nell'argomento. Esegui lo script seguente per creare un carico di lavoro in cui vengono eseguiti i passaggi seguenti:

Crea Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) di proprietà della banca Secundus.
Aggiorna il codice del carico di lavoro con i nomi delle risorse richiesti. Qui puoi trovare il codice del carico di lavoro utilizzato per questo codelab.
Crea il file binario Go e il Dockerfile per creare un'immagine Docker del codice del carico di lavoro. Qui puoi trovare il Dockerfile utilizzato per questo codelab.
Crea e pubblica l'immagine Docker in Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) di proprietà della banca Secundus.
Concedi a $WORKLOAD_SERVICEACCOUNT l'autorizzazione di lettura per $SECUNDUS_ARTIFACT_REGISTRY. Questa operazione è necessaria affinché il container dei carichi di lavoro possa eseguire il pull dell'immagine Docker dei carichi di lavoro da Artifact Registry.

$ ./create_workload.sh

Firma carico di lavoro

Utilizzeremo Cosign per firmare l'immagine del carico di lavoro. Per impostazione predefinita, Cosign archivia 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.

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

Creare un repository Docker di Artifact Registry.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=us

Crea un keyring e una chiave in KMS per firmare un'immagine del carico di lavoro.

$ gcloud config set project $PRIMUS_PROJECT_ID

$ gcloud kms keyrings create $PRIMUS_SIGNING_KEYRING \
  --location=global

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

Per Artifact Registry, è previsto un nome completo dell'immagine, come $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 all'account di servizio $WORKLOAD_SERVICEACCOUNT il ruolo Visualizzatore per il repository $PRIMUS_COSIGN_REPOSITORY. In questo modo Confidential Space può rilevare le firme delle immagini container caricate su $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 è un potente strumento con più funzionalità di firma. Per il nostro caso d'uso, chiediamo a Cosign di firmare solo con una coppia di chiavi. La firma senza chiave Cosign non è supportata per questa funzionalità dell'immagine container firmata.

Quando firmi con una coppia di chiavi, hai due opzioni:

Firma con una coppia di chiavi locali 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 maggiori dettagli, consulta l'articolo Firma con chiavi autogestite.

// 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

In quanto riportato sopra, 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 in uso
<key> : indica il 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 carico di lavoro utilizzando Cosign. Esegui la codifica Base64 senza riempimenti sulla chiave pubblica.

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

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

Firma il carico di lavoro utilizzando Cosign con la chiave pubblica e gli algoritmi di firma esportati collegati.

$ 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 quale chiave di firma utilizzare. Quando fai riferimento a una chiave gestita da un provider KMS, segui il formato URI specifico dell'assistenza KMS di Sigstore. Quando fai riferimento a una chiave generata da Cosign, utilizza invece cosign.key.
$IMAGE_REFERENCE [OBBLIGATORIO] specifica l'immagine container da firmare. Il formato di IMAGE_REFERENCE può essere identificato dal tag o dal digest 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]
-a [OBBLIGATORIO] specifica le annotazioni allegate al payload della firma. Per le immagini container firmate Confidential Space, la chiave pubblica e gli algoritmi di firma devono essere collegati al payload della firma.

dev.cosignproject.cosign/sigalg accetta SOLO tre valori:
RSASSA_PSS_SHA256: algoritmo RSASSA con spaziatura interna PSS con un digest SHA256.
RSASSA_PKCS1V15_SHA256: algoritmo RSASSA con spaziatura interna 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.

Carica le firme nel repository Docker

Il segno cosign caricherà automaticamente le firme nel COSIGN_REPOSITORY. specificato

4. Autorizza ed esegui carico di lavoro

Autorizza carico di lavoro

Nell'ambito di questo passaggio, configureremo il provider di identità per i carichi di lavoro nel pool di identità per i carichi di lavoro ($PRIMUS_WORKLOAD_IDENTITY_POOL). Per l'identità del carico di lavoro 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 carico di lavoro, Primus Bank controlla il codice del carico di lavoro e firma la nuova immagine del carico di lavoro senza dover aggiornare il criterio in fase di elaborazione 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 carico di lavoro

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 dei carichi di lavoro vengono passati utilizzando "tee-cmd" della segnalazione. Il carico di lavoro è codificato per pubblicare il risultato su $SECUNDUS_RESULT_STORAGE_BUCKET.

$ gcloud config set project $SECUNDUS_PROJECT_ID

$ gcloud compute instances create signed-container-vm \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=TERMINATE \
 --scopes=cloud-platform --zone=us-west1-b \
 --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 carico di lavoro.

$ gcloud config set project $SECUNDUS_PROJECT_ID

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

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

5. Esegui la pulizia

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

Bucket di archiviazione di input della banca Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Conto di servizio bancario Primus ($PRIMUS_SERVICEACCOUNT).
Artifact Registry di Primus Bank contenente le firme delle immagini ($PRIMUS_COSIGN_REPOSITORY).
Pool di identità per i carichi di lavoro di Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Account di servizio per i carichi di lavoro di Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
dell'istanza Compute del carico di lavoro.
Bucket di archiviazione dei risultati di Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Artifact Registry di Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY).

// run the clean up script to delete the resources created as part of this codelab.
$ ./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 e fai clic su "Elimina". in alto: in questo modo viene pianificata l'eliminazione del progetto

Complimenti

Congratulazioni, hai completato il codelab.

Hai imparato a sfruttare la funzionalità dell'immagine container firmata per migliorare l'usabilità di Confidential Space.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab simili...