Questa pagina è stata tradotta dall'API Cloud Translation.

Codelab sull'immagine container firmata

1. Panoramica

Questo codelab si basa sul codelab Spazio riservato. Il supporto delle immagini container firmate offre la possibilità di autenticare un contenitore utilizzando una chiave pubblica attestata anziché specificare il digest dell'immagine nel criterio del pool di identità del workload (WIP).

Cosa è cambiato con il supporto delle immagini container firmate in Spazio privato:

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

Quando utilizzi 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. Se utilizzi le firme delle immagini, il criterio 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 delle immagini attendibile è più pratico che aggiornare un elenco di nuovi valori digest delle immagini.

Nessuna regressione della sicurezza: questo approccio alla firma del contenitore non comporterà alcuna regressione della sicurezza rispetto all'approccio precedente basato sui digest delle immagini, in quanto i confini di attendibilità rimangono invariati. Nell'approccio con firma del contenitore, 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 dal criterio WIP. Il servizio di verifica dell'attestazione verifica che la firma sia associata al carico di lavoro 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 dose di attendibilità al firmatario dell'immagine. Specificando l'impronta della chiave pubblica di un firmatario attendibile nel criterio di attestazione, il proprietario della risorsa autorizza il firmatario a rilasciare raccomandazioni sulle immagini container che soddisfano un criterio. Il servizio di verifica dell'attestazione verifica che la firma sia associata al carico di lavoro 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 indirizzamento fornito dalla firma dell'immagine mantiene le garanzie di sicurezza elevate dello spazio riservato.

L'unica differenza tra questi approcci è che quest'ultimo utilizza un livello aggiuntivo di indirizzamento in cui le immagini del carico di lavoro sono autorizzate con una chiave di firma. Ciò non introduce nuove vulnerabilità di sicurezza perché i confini di attendibilità rimangono invariati.

Cosa imparerai a fare

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

Come firmare un'immagine container sottoposta a controllo 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 l'esecuzione di Spazio riservato
Come eseguire il carico di lavoro in uno spazio riservato con il supporto delle immagini container firmate

Questo codelab mostra come utilizzare Confidential Space per eseguire l'attestazione da remoto di un'immagine contenitore 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 di Sigstore cosign
Conoscenze di base di Google Compute Engine ( codelab), Confidential VM, Container e repository remoti
Conoscenze di base di Cloud KMS ( codelab)
Conoscenze di base su 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à l'auditor e il proprietario della risorsa, responsabile di quanto segue:

Configurazione delle risorse richieste con dati di esempio.
Controllo del codice del carico di lavoro.
Utilizzo di cosign per firmare l'immagine del carico di lavoro.
Caricamento della firma in un repository.
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 necessarie per memorizzare il risultato.
Scrittura del codice del carico di lavoro.
Pubblicazione dell'immagine del carico di lavoro.
Eseguire il carico di lavoro in uno spazio riservato con il supporto delle immagini container firmate.

La Banca Secundus svilupperà e pubblicherà un carico di lavoro che eseguirà query sui dati dei clienti archiviati in un bucket Cloud Storage di proprietà della Banca Primus. Primus Bank controllerà il carico di lavoro, firmerà l'immagine del contenitore e configurerà i criteri WIP per consentire l'accesso ai propri dati da parte dei 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 uno spazio riservato

Questo codelab fa riferimento a una serie di variabili che devi impostare su 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 delle risorse 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 dei dati del cliente.
$PRIMUS_WORKLOAD_IDENTITY_POOL: il pool di identità del workload (WIP) che convalida i claim.
$PRIMUS_WIP_PROVIDER: il fornitore del 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: l'account di servizio 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: l'Artifact Registry per archiviare le firme delle immagini del carico di lavoro.
$PRIMUS_SIGNING_KEY: la chiave KMS utilizzata per firmare l'immagine del carico di lavoro da parte di revisori/collaboratori dei 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 del carico di lavoro.
$WORKLOAD_IMAGE_NAME: il nome dell'immagine Docker del workload.
$WORKLOAD_IMAGE_TAG: il tag dell'immagine Docker del carico di lavoro.
$WORKLOAD_SERVICEACCOUNT: l'account di servizio che ha l'autorizzazione ad accedere alla VM Confidential che esegue il carico di lavoro.
$SECUNDUS_RESULT_BUCKET: il bucket che memorizza i risultati del carico di lavoro.

Altre risorse:

primus_customer_list.csv contiene i dati del cliente. Caricheremo questi dati in $PRIMUS_INPUT_STORAGE_BUCKET e creeremo un carico di lavoro che eseguirà query su questi dati.

Flusso di lavoro esistente

Quando esegui il carico di lavoro in Confidential Space, viene eseguita la seguente procedura utilizzando le risorse configurate:

Il carico di lavoro richiede un token di accesso generale di Google per $PRIMUS_SERVICEACCOUNT dal WIP. Offre un token di servizio Attestation Verifier con claim relativi a workload e ambiente.
Se le rivendicazioni di misurazione del carico di lavoro nel token di servizio del verificatore 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 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 dei container firmati

Il supporto dei contenitori firmati verrà integrato nel flusso di lavoro esistente, come evidenziato di seguito. Quando esegui il carico di lavoro in uno spazio riservato con il supporto delle immagini container firmate, viene eseguita la seguente procedura utilizzando le risorse configurate:

Confidential Space rileva eventuali firme dei container correlate all'immagine del carico di lavoro attualmente in esecuzione e le invia al verificatore dell'attestazione. Il verificatore dell'attestazione verifica la firma e include eventuali firme valide nelle dichiarazioni di attestazione.
Il carico di lavoro richiede un token di accesso generale di Google per $PRIMUS_SERVICEACCOUNT dal WIP. Offre un token di servizio Attestation Verifier con claim relativi a 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 carico di lavoro 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, dovrai prima creare le risorse cloud necessarie nei progetti Google Cloud delle banche Primus e Secundus. Di seguito sono riportate le risorse nuove di questo codelab:

Nel progetto Primus:

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

Non ci sono nuove risorse nel progetto Secundus. Una volta configurate queste risorse, dovrai creare un account di servizio per il carico di lavoro con i ruoli e le autorizzazioni richiesti. Poi creerai un'immagine del workload e il revisore, 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 (in questo caso Secundus Bank) lo eseguirà.

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 riportato di seguito per ottenere gli script richiesti utilizzati nell'ambito di questo codelab.

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

Modifica 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 sopra indicati 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 bancarie Primus

In questo passaggio, configurerai le risorse cloud necessarie 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 indicate di seguito:

Bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) per archiviare il file dei dati dei clienti criptati 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 i claim in base alle condizioni degli attributi configurate nel relativo provider.
Account di servizio ($PRIMUS_SERVICEACCOUNT) associato al pool di identità del carico di lavoro ($PRIMUS_WORKLOAD_IDENTITY_POOL) sopra indicato 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 collegare questo account di servizio al pool di identità del workload.

./setup_primus_bank_resources.sh

Configurare le risorse bancarie di Secundus

In questo passaggio, configurerai le risorse cloud necessarie 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 indicate 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 account di servizio per il workload

Ora crea un account di servizio per il carico di lavoro con i ruoli e le autorizzazioni richiesti. Esegui il seguente script per creare un account di servizio per il carico 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 del carico di lavoro ($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 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 workload

In questo passaggio, creerai un'immagine Docker del tuo workload. Il carico di lavoro utilizzato in questo Codelab è una semplice app Go basata su CLI che conteggia i clienti (dai dati dei clienti della banca Primus) di una località geografica fornita nell'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 carico di lavoro con i nomi delle risorse richieste. Qui è riportato il codice del carico di lavoro utilizzato per questo codelab.
Compila il file binario Go e crea il file Dockerfile per la creazione di 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. Questo è necessario per consentire al container del workload di estrarre l'immagine Docker del workload da Artifact Registry.

./create_workload.sh

Firma il workload

Utilizzeremo Cosign per firmare l'immagine del carico di lavoro. 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 d'ambiente COSIGN_REPOSITORY.

Qui utilizzeremo Artifact Registry come esempio. In base alle tue preferenze, puoi anche scegliere altri registry basati su OCI come Docker Hub e AWS CodeArtifact.

Crea un repository Docker di 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 immagine completo 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 il ruolo Visualizzatore nel repository $PRIMUS_COSIGN_REPOSITORY all'account di servizio $WORKLOAD_SERVICEACCOUNT. In questo modo, Confidential Space può rilevare eventuali firme delle immagini container caricate nel $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 che Cosign firmi con una coppia di chiavi. La firma senza chiave Cosign non è supportata per questa funzionalità di immagini container firmate.

Quando firmi con una coppia di chiavi, hai 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 sulla firma con chiavi gestite autonomamente. Qui abbiamo specificato entrambi i modi (localmente e utilizzando il provider KMS) per generare la coppia di chiavi e firmare il carico di lavoro. Segui uno di questi metodi per firmare il contenitore del carico di lavoro.

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

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> : fa riferimento 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 carico di lavoro 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 carico di lavoro utilizzando Cosign con la chiave pubblica esportata e gli algoritmi di firma 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 indicato nell'assistenza KMS di Sigstore. Quando fai riferimento a una chiave generata da Cosign, utilizza cosign.key.
$IMAGE_REFERENCE [OBBLIGATORIO] specifica l'immagine del contenitore da firmare. Il formato di IMAGE_REFERENCE può essere identificato tramite tag o digest di immagini. 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 contenitore firmate di Confidential Space, è necessario che le chiavi pubbliche e gli algoritmi di firma siano allegati al payload della firma.

dev.cosignproject.cosign/sigalg SOLO accetta tre valori:
RSASSA_PSS_SHA256: algoritmo RSASSA con padding PSS e 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. Si tratta anche dell'algoritmo di firma predefinito per le coppie di chiavi generate da Cosign.

Carica le firme nel repository Docker

La firma Cosign caricherà automaticamente le firme nell'account COSIGN_REPOSITORY. specificato

4. Autorizza ed esegui il carico di lavoro

Autorizza il workload

In questo passaggio, configureremo il fornitore di identità del workload nel pool di identità del workload ($PRIMUS_WORKLOAD_IDENTITY_POOL). Esistono condizioni degli attributi configurate per l'identità del workload, 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 la Banca Secundus rilascia una nuova immagine del carico di lavoro, la Banca Primus controlla il codice del carico di lavoro e firma la nuova immagine del carico di lavoro 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

In 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 contenitore del workload vengono passati utilizzando la parte "tee-cmd" del flag. Il carico di lavoro è codificato per pubblicare il risultato in $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 carico di lavoro.

gcloud config set project $SECUNDUS_PROJECT_ID

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

Il risultato dovrebbe essere 3, ovvero il numero di persone di Seattle elencate nel file primus_customer_list.csv.

5. Esegui la pulizia

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

Bucket di archiviazione di input della banca Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Account di servizio della banca Primus ($PRIMUS_SERVICEACCOUNT).
Registry di elementi della banca Primus 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 della Banca Secundus ($WORKLOAD_SERVICEACCOUNT).
Istanze di calcolo del carico di lavoro.
Bucket di archiviazione dei risultati della Banca Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).
Registry degli elementi della Banca Secundus ($SECUNDUS_ARTIFACT_REGISTRY).
VM del carico di lavoro della Banca Secundus ($WORKLOAD_VM).

./cleanup.sh

Se hai finito di esplorare, valuta la possibilità di eliminare il progetto.

Vai alla console della piattaforma Cloud.
Seleziona il progetto che vuoi arrestare e fai clic su "Elimina" in alto per pianificarne l'eliminazione.

Complimenti

Complimenti, hai completato il codelab.

Hai imparato a sfruttare la funzionalità di immagine contenitore firmata per migliorare l'usabilità di Spazio riservato.

Passaggi successivi

Dai un'occhiata ad alcuni di questi codelab simili…