Atelier de programmation sur les images de conteneur signées

1. Présentation

Cet atelier de programmation s'appuie sur l'atelier de programmation Confidential Space. Prise en charge des images de conteneurs signées avec une option permettant d'authentifier un conteneur à l'aide d'une clé publique attestée au lieu de spécifier le résumé de l'image dans le règlement du pool d'identités de charge de travail.

Modifications apportées à la compatibilité avec les images de conteneurs signées dans Confidential Space :

Usabilité améliorée : avec l'introduction de la fonctionnalité d'image de conteneur signée, nous pouvons désormais passer d'une approche de condensé d'image de charge de travail à une approche de signature de conteneur pour les collaborateurs/auditeurs autorisant une image.

Lorsqu'ils utilisent directement les condensés d'image, les propriétaires de ressources doivent mettre à jour leurs règles avec un condensé d'image chaque fois qu'ils autorisent une nouvelle image. En utilisant des signatures d'image, la règle contient une empreinte de clé publique, dont la clé privée correspondante appartient au collaborateur/auditeur et est utilisée pour signer les images auditées.
Pour certains modèles de sécurité, il est plus pratique de faire référence à une clé de signature d'image de confiance que de mettre à jour une liste de nouvelles valeurs de résumé d'image.

Aucune régression de sécurité : cette approche de signature de conteneur n'entraînera aucune régression de sécurité par rapport à l'approche précédente de résumé d'image, car les limites de confiance restent les mêmes. Dans l'approche de signature de conteneur, le propriétaire de la ressource autorise une clé de validation en spécifiant l'empreinte de clé publique de confiance dans la règle WIP. La vérification de l'autorisation est effectuée par le service de validation d'attestation et WIP. Le service de validation d'attestation vérifie que la signature est associée à la charge de travail en cours d'exécution, et la règle WIP vérifie que la clé publique affirmée par le service est autorisée par la règle.

Sécurité renforcée : l'utilisation de signatures d'images de conteneurs permet de déléguer un certain niveau de confiance au signataire de l'image. En spécifiant l'empreinte de clé publique d'un signataire de confiance dans la stratégie d'attestation, le propriétaire de la ressource autorise ce signataire à émettre des recommandations sur les images de conteneur qui respectent une stratégie. Le service de validation d'attestation vérifie que la signature est associée à la charge de travail en cours d'exécution, et la règle vérifie que la clé publique qui a créé la signature est autorisée par la règle. Grâce à cela, la couche d'indirection supplémentaire fournie par la signature d'image maintient les garanties de sécurité solides de Confidential Space.

La seule différence entre ces approches est que la seconde utilise une couche d'indirection supplémentaire où les images de charge de travail sont autorisées avec une clé de signature. Cela n'introduit aucune nouvelle faille de sécurité, car les limites de confiance restent les mêmes.

Points abordés

Dans cet atelier de programmation, vous allez apprendre à utiliser une signature d'image de conteneur pour autoriser l'accès à des ressources protégées :

Signer une image de conteneur auditée à l'aide de cosign
Importer des signatures d'images de conteneurs dans des registres OCI pour la découverte et le stockage des signatures
Configurer les ressources cloud nécessaires pour exécuter Confidential Space
Exécuter la charge de travail dans un espace confidentiel avec la compatibilité des images de conteneurs signées

Cet atelier de programmation vous explique comment utiliser Confidential Space pour attester à distance d'une image de conteneur signée par une clé de confiance s'exécutant sur Google Compute Engine.

Prérequis

Terminer l'atelier de programmation Confidential Space
Un projet Google Cloud Platform
Un navigateur tel que Chrome ou Firefox
Une bonne connaissance des éditeurs de texte Linux standards tels que Vim, Emacs ou Nano
Connaissances de base sur Sigstore cosign
Connaissances de base de Google Compute Engine ( atelier de programmation), Confidential VM, Conteneurs et dépôts distants
Connaissances de base de Cloud KMS ( atelier de programmation)
Connaissances de base des comptes de service, de la fédération d'identité de charge de travail et des conditions d'attributs.
Connaissances de base sur Artifact Registry
Connaissances de base sur les signatures numériques

Rôles impliqués dans un espace confidentiel avec une image de conteneur signée

Dans cet atelier de programmation, Primus Bank sera l'auditeur et le propriétaire de la ressource, qui sera responsable des éléments suivants :

Configurer les ressources requises avec des exemples de données.
Auditez le code de la charge de travail.
Utiliser cosign pour signer l'image de charge de travail.
Importer la signature dans un dépôt.
Configuration d'une règle WIP pour protéger les données client.

Secundus Bank sera l'auteur et l'opérateur de la charge de travail, et sera responsable des éléments suivants :

Configurer les ressources requises pour stocker le résultat.
Écrivez le code de la charge de travail.
Publiez l'image de charge de travail.
Exécuter la charge de travail dans Confidential Space avec la prise en charge des images de conteneurs signées.

La banque Secundus développera et publiera une charge de travail qui interrogera les données client stockées dans un bucket Cloud Storage appartenant à la banque Primus. La banque Primus auditera la charge de travail, signera l'image de conteneur et configurera les règles WIP pour autoriser l'accès à ses données par les charges de travail approuvées. Le résultat de l'exécution de cette charge de travail sera stocké dans un bucket Cloud Storage appartenant à la banque Secundus.

Ressources impliquées dans la configuration de Confidential Space

Cet atelier de programmation fait référence à un certain nombre de variables que vous devez définir sur des valeurs appropriées pour votre projet GCP. Les commandes de cet atelier de programmation supposent que ces variables ont été définies. (par exemple, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' peut être utilisé pour définir le nom du bucket de stockage d'entrée de la banque Primus). Si les variables des noms de ressources n'ont pas été définies, elles seront générées en fonction de l'ID du projet GCP.

Configurez les éléments suivants dans le projet Primus :

$PRIMUS_INPUT_STORAGE_BUCKET : bucket qui stocke le fichier de données client.
$PRIMUS_WORKLOAD_IDENTITY_POOL : pool d'identités de charge de travail qui valide les revendications.
$PRIMUS_WIP_PROVIDER : fournisseur de pools d'identités de charge de travail qui inclut la condition d'autorisation à utiliser pour les jetons signés par le service de validation d'attestation.
$PRIMUS_SERVICEACCOUNT : compte de service utilisé par $PRIMUS_WORKLOAD_IDENTITY_POOL pour accéder aux ressources protégées. À cette étape, il est autorisé à afficher les données client stockées dans le bucket $PRIMUS_INPUT_STORAGE_BUCKET.
$PRIMUS_ENC_KEY : clé KMS utilisée pour chiffrer les données stockées dans $PRIMUS_INPUT_STORAGE_BUCKET.

Nouvelles ressources pour cet atelier de programmation :

$PRIMUS_COSIGN_REPOSITORY : Artifact Registry pour stocker les signatures d'images de charge de travail.
$PRIMUS_SIGNING_KEY : clé KMS utilisée pour signer l'image de charge de travail par les auditeurs/collaborateurs de données (par exemple, la banque Primus dans ce cas).

Configurez les éléments suivants dans le projet Secundus :

$SECUNDUS_ARTIFACT_REGISTRY : Artifact Registry où l'image Docker de la charge de travail sera transférée.
$WORKLOAD_IMAGE_NAME : nom de l'image Docker de la charge de travail.
$WORKLOAD_IMAGE_TAG : tag de l'image Docker de la charge de travail.
$WORKLOAD_SERVICEACCOUNT : compte de service autorisé à accéder à la VM confidentielle qui exécute la charge de travail.
$SECUNDUS_RESULT_BUCKET : bucket qui stocke les résultats de la charge de travail.

Autres ressources :

primus_customer_list.csv contient les données client. Nous allons importer ces données dans $PRIMUS_INPUT_STORAGE_BUCKET et créer une charge de travail qui interrogera ces données.

Workflow existant

Lorsque vous exécutez la charge de travail dans Confidential Space, le processus suivant a lieu à l'aide des ressources configurées :

La charge de travail demande un jeton d'accès Google général pour $PRIMUS_SERVICEACCOUNT à partir du WIP. Il propose un jeton de service Attestation Verifier avec des revendications de charge de travail et d'environnement.
Si les revendications de mesure de charge de travail dans le jeton du service Attestation Verifier correspondent à la condition d'attribut dans le WIP, le jeton d'accès pour $PRIMUS_SERVICEACCOUNT. est renvoyé.
La charge de travail utilise le jeton d'accès au compte de service associé à $PRIMUS_SERVICEACCOUNT pour accéder aux données client dans le bucket $PRIMUS_INPUT_STORAGE_BUCKET.
La charge de travail effectue une opération sur ces données.
La charge de travail utilise le compte de service $WORKLOAD_SERVICEACCOUNT pour écrire les résultats de cette opération dans le bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

Nouveau workflow avec prise en charge des conteneurs signés

La compatibilité avec les conteneurs signés sera intégrée au workflow existant, comme indiqué ci-dessous. Lorsque vous exécutez la charge de travail dans Confidential Space avec la prise en charge des images de conteneur signées, le processus suivant se déroule à l'aide des ressources configurées :

Confidential Space détecte les signatures de conteneurs liées à l'image de charge de travail en cours d'exécution et les envoie au vérificateur d'attestation. L'outil de validation des attestations valide la signature et inclut toutes les signatures valides dans les revendications d'attestation.
La charge de travail demande un jeton d'accès Google général pour $PRIMUS_SERVICEACCOUNT à partir du WIP. Il propose un jeton de service Attestation Verifier avec des revendications de charge de travail et d'environnement.
Si les revendications de signature du conteneur dans le jeton du service Attestation Verifier correspondent à la condition d'attribut dans le WIP, le jeton d'accès pour $PRIMUS_SERVICEACCOUNT est renvoyé.
La charge de travail utilise le jeton d'accès au compte de service associé à $PRIMUS_SERVICEACCOUNT pour accéder aux données client dans le bucket $PRIMUS_INPUT_STORAGE_BUCKET.
La charge de travail effectue une opération sur ces données.
La charge de travail utilise $WORKLOAD_SERVICEACCOUNT pour écrire les résultats de cette opération dans le bucket $SECUNDUS_RESULT_STORAGE_BUCKET.

2. Configurer les ressources cloud

Lors de la configuration de Confidential Space, vous devez d'abord créer les ressources cloud requises dans les projets GCP des banques Primus et Secundus. Voici les ressources nouvelles dans cet atelier de programmation :

Dans le projet Primus :

Clé de signature KMS utilisée pour signer les charges de travail Secundus, après audit du code.
Dépôt Artifact Registry pour stocker les signatures Cosign.

Le projet Secundus ne contient aucune nouvelle ressource. Une fois ces ressources configurées, vous créerez un compte de service pour la charge de travail avec les rôles et autorisations requis. Vous allez ensuite créer une image de charge de travail, que l'auditeur, la banque Primus, signera. La charge de travail sera ensuite autorisée par les collaborateurs de données (banque Primus dans cet atelier de programmation), et l'opérateur de charge de travail (banque Secundus dans ce cas) l'exécutera.

Lors de la configuration de Confidential Space, vous allez créer les ressources cloud requises dans les projets GCP Primus et Secundus.

Avant de commencer

Clonez ce dépôt à l'aide de la commande ci-dessous pour obtenir les scripts requis utilisés dans cet atelier de programmation.

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

Accédez au répertoire de cet atelier de programmation.

cd confidential-space/codelabs/signed_container_codelab/scripts

Assurez-vous d'avoir défini les projets requis, comme indiqué ci-dessous.

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

Définissez les variables pour les noms de ressources mentionnés ci-dessus à l'aide de cette commande. Vous pouvez remplacer les noms de ressources à l'aide de ces variables (par exemple, export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket').
Exécutez le script suivant pour définir les noms de variables restants sur des valeurs basées sur l'ID de votre projet pour les noms de ressources.

source config_env.sh

Installez cosign en suivant les instructions ici.

Configurer les ressources de la banque Primus

Au cours de cette étape, vous allez configurer les ressources cloud requises pour la banque Primus. Exécutez le script suivant pour configurer les ressources de la banque Primus. Au cours de ces étapes, les ressources mentionnées ci-dessous seront créées :

Bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) pour stocker le fichier de données client chiffré de la banque Primus.
Clé de chiffrement ($PRIMUS_ENC_KEY) et trousseau de clés ($PRIMUS_ENC_KEYRING) dans KMS pour chiffrer le fichier de données de la banque Primus.
Pool d'identités de charge de travail ($PRIMUS_WORKLOAD_IDENTITY_POOL) permettant de valider les revendications en fonction des conditions d'attributs configurées sous son fournisseur.
Compte de service ($PRIMUS_SERVICEACCOUNT) associé au pool d'identités de charge de travail mentionné ci-dessus ($PRIMUS_WORKLOAD_IDENTITY_POOL) avec les accès IAM suivants :
roles/cloudkms.cryptoKeyDecrypter pour déchiffrer les données à l'aide de la clé KMS.
objectViewer pour lire les données du bucket Cloud Storage.
roles/iam.workloadIdentityUser pour associer ce compte de service au pool d'identités de charge de travail.

./setup_primus_bank_resources.sh

Configurer les ressources bancaires Secundus

Au cours de cette étape, vous allez configurer les ressources cloud requises pour la banque Secundus. Exécutez le script suivant pour configurer les ressources de la banque Secundus. Les ressources mentionnées ci-dessous seront créées au cours de ces étapes :

Bucket Cloud Storage ($SECUNDUS_RESULT_STORAGE_BUCKET) pour stocker le résultat de l'exécution de la charge de travail par la banque Secundus.

./setup_secundus_bank_resources.sh

3. Créer et signer une charge de travail

Créer un compte de service de charge de travail

Vous allez maintenant créer un compte de service pour la charge de travail avec les rôles et autorisations requis. Exécutez le script suivant pour créer un compte de service de charge de travail dans le projet de la banque Secundus. Ce compte de service sera utilisé par la VM qui exécute la charge de travail.

Ce compte de service de charge de travail ($WORKLOAD_SERVICEACCOUNT) disposera des rôles suivants :
confidentialcomputing.workloadUser pour obtenir un jeton d'attestation
logging.logWriter pour écrire des journaux dans Cloud Logging.
objectViewer pour lire les données du bucket Cloud Storage $PRIMUS_INPUT_STORAGE_BUCKET.
objectAdmin pour écrire le résultat de la charge de travail dans le bucket Cloud Storage $SECUNDUS_RESULT_STORAGE_BUCKET.

./create_workload_serviceaccount.sh

Créer une charge de travail

Dans cette étape, vous allez créer une image Docker de charge de travail. La charge de travail utilisée dans cet atelier de programmation est une application Go simple basée sur l'interface de ligne de commande, qui compte les clients (à partir des données client de la banque Primus) d'une zone géographique fournie en argument. Exécutez le script suivant pour créer une charge de travail dans laquelle les étapes suivantes sont effectuées :

Créez un dépôt Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY) appartenant à la banque Secundus.
Mettez à jour le code de la charge de travail avec les noms des ressources requises. Cliquez ici pour accéder au code de charge de travail utilisé pour cet atelier de programmation.
Créez un fichier binaire Go et un fichier Dockerfile pour créer une image Docker du code de charge de travail. Voici le Dockerfile utilisé pour cet atelier de programmation.
Créez et publiez l'image Docker dans Artifact Registry ($SECUNDUS_ARTIFACT_REGISTRY) appartenant à la banque Secundus.
Accordez l'autorisation de lecture $WORKLOAD_SERVICEACCOUNT pour $SECUNDUS_ARTIFACT_REGISTRY. Cela est nécessaire pour que le conteneur de charge de travail puisse extraire l'image Docker de charge de travail à partir d'Artifact Registry.

./create_workload.sh

Signer la charge de travail

Nous utiliserons Cosign pour signer l'image de charge de travail. Par défaut, Cosign stocke les signatures dans le même dépôt que l'image qu'il signe. Pour spécifier un autre dépôt pour les signatures, vous pouvez définir la variable d'environnement COSIGN_REPOSITORY.

Nous allons utiliser Artifact Registry comme exemple. Vous pouvez également choisir d'autres registres basés sur OCI, tels que Docker Hub ou AWS CodeArtifact, selon vos préférences.

Créez un dépôt 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}

Créez un trousseau et une clé sous KMS pour signer une image de charge de travail.

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}

Pour Artifact Registry, un nom d'image complet tel que $LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME est attendu. Vous pouvez importer n'importe quelle image de conteneur dans le dépôt pour stocker la signature.

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

Attribuez le rôle Lecteur au compte de service $WORKLOAD_SERVICEACCOUNT dans le dépôt $PRIMUS_COSIGN_REPOSITORY. Cela permet à Confidential Space de découvrir les signatures d'images de conteneurs importées dans $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 est un outil puissant doté de plusieurs fonctionnalités de signature. Dans notre cas d'utilisation, nous n'avons besoin que de Cosign pour signer avec une paire de clés. La signature sans clé Cosign n'est pas compatible avec cette fonctionnalité d'image de conteneur signée.

Lorsque vous signez avec une paire de clés, deux options s'offrent à vous :

Signez avec une paire de clés locale générée par Cosign.
Signez avec une paire de clés stockée ailleurs (par exemple, dans un KMS).

Générez une paire de clés dans Cosign si vous n'en avez pas. Pour en savoir plus, consultez Signer avec des clés autogérées. Ici, nous avons spécifié les deux méthodes (localement et à l'aide du fournisseur KMS) pour générer une paire de clés et signer la charge de travail. Veuillez suivre l'une de ces méthodes pour signer le conteneur de charge de travail.

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

Dans la ligne ci-dessus, remplacez <provider>://<key> par gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION.

<provider> : fait référence à la solution KMS que vous utilisez.
<key> : fait référence au chemin d'accès de la clé dans KMS.

Récupérez la clé publique pour la validation.

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

Signez la charge de travail à l'aide de Cosign. Effectuez un encodage base64 sans remplissage sur la clé publique.

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

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

Signez la charge de travail à l'aide de Cosign avec les algorithmes de clé publique et de signature exportés.

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 [OBLIGATOIRE] spécifie la clé de signature à utiliser. Lorsque vous faites référence à une clé gérée par un fournisseur KMS, veuillez suivre le format URI spécifique de la compatibilité KMS de Sigstore. Lorsque vous faites référence à une clé générée par Cosign, utilisez plutôt cosign.key.
$IMAGE_REFERENCE [REQUIRED] spécifie l'image de conteneur à signer. Le format de IMAGE_REFERENCE peut être identifié par un tag ou un condensé d'image. Par exemple : 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 [REQUIRED] spécifie les annotations associées à la charge utile de la signature. Pour les images de conteneurs signées Confidential Space, les algorithmes de clé publique et de signature doivent être associés à la charge utile de la signature.

dev.cosignproject.cosign/sigalg ONLY accepte trois valeurs :
RSASSA_PSS_SHA256 : algorithme RSASSA avec remplissage PSS et condensé SHA256.
RSASSA_PKCS1V15_SHA256 : algorithme RSASSA avec remplissage PKCS#1 v1.5 et condensé SHA256.
ECDSA_P256_SHA256 : ECDSA sur la courbe P-256 avec un condensé SHA256. Il s'agit également de l'algorithme de signature par défaut pour les paires de clés générées par Cosign.

Importer des signatures dans le dépôt Docker

Cosign Sign importe automatiquement les signatures dans le COSIGN_REPOSITORY. spécifié.

4. Autoriser et exécuter la charge de travail

Autoriser la charge de travail

Dans cette étape, nous allons configurer le fournisseur d'identité de charge de travail sous le pool d'identités de charge de travail ($PRIMUS_WORKLOAD_IDENTITY_POOL). Des conditions d'attributs sont configurées pour l'identité de charge de travail, comme indiqué ci-dessous. L'une des conditions consiste à valider l'empreinte de la signature de l'image de charge de travail par rapport à l'empreinte de la clé publique de signature. Avec cette condition d'attribut, lorsque Secundus Bank publie une nouvelle image de charge de travail, Primus Bank audite le code de la charge de travail et signe la nouvelle image de charge de travail sans avoir à mettre à jour la règle WIP avec le résumé de l'image.

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))"

Exécuter la charge de travail

Au cours de cette étape, nous allons exécuter la charge de travail sur une Confidential VM. Les arguments TEE requis sont transmis à l'aide de l'indicateur de métadonnées. Les arguments du conteneur de charge de travail sont transmis à l'aide de la partie "tee-cmd" de l'indicateur. La charge de travail est codée pour publier son résultat sur $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"

Afficher les résultats

Dans le projet Secundus, affichez les résultats de la charge de travail.

gcloud config set project $SECUNDUS_PROJECT_ID

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

Le résultat doit être 3, car c'est le nombre de personnes de Seattle listées dans le fichier primus_customer_list.csv.

5. Effectuer un nettoyage

Voici le script qui peut être utilisé pour nettoyer les ressources que nous avons créées dans cet atelier de programmation. Dans le cadre de ce nettoyage, les ressources suivantes seront supprimées :

Bucket de stockage d'entrée de la banque Primus ($PRIMUS_INPUT_STORAGE_BUCKET).
Compte de service bancaire Primus ($PRIMUS_SERVICEACCOUNT).
Registre des artefacts de la banque Primus, qui contient les signatures d'images ($PRIMUS_COSIGN_REPOSITORY).
Pool d'identité de charge de travail Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Compte de service de charge de travail de Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Instance de calcul de charge de travail.
Bucket de stockage des résultats de Secundus Bank ($SECUNDUS_RESULT_STORAGE_BUCKET).
Registre d'artefacts de la banque Secundus ($SECUNDUS_ARTIFACT_REGISTRY).
VM de charge de travail de Secundus Bank ($WORKLOAD_VM).

./cleanup.sh

Si vous avez terminé l'exploration, pensez à supprimer votre projet.

Accédez à la console Cloud Platform.
Sélectionnez le projet que vous souhaitez arrêter, puis cliquez sur "Supprimer" en haut de la page. Le projet est alors programmé pour suppression.

Félicitations

Bravo ! Vous avez terminé cet atelier de programmation.

Vous avez appris à tirer parti de la fonctionnalité d'image de conteneur signée pour améliorer la facilité d'utilisation de Confidential Space.

Et ensuite ?

Découvrez quelques-uns de ces ateliers de programmation similaires :