Cette page a été traduite par l'API Cloud Translation.

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. Compatibilité des images de conteneurs signées avec la possibilité d'authentifier un conteneur à l'aide d'une clé publique certifiée au lieu de spécifier un condensé de l'image dans la règle du pool d'identités de charge de travail (WIP).

Ce qui a changé avec la prise en charge des images de conteneurs signées dans Confidential Space:

Facilité d'utilisation améliorée:grâce à l'introduction de la fonctionnalité d'image de conteneur signée, nous pouvons passer d'une approche condensée de l'image de charge de travail à une approche de signature de conteneur pour les collaborateurs/auditeurs qui autorisent une image.

Lorsqu'ils utilisent directement des condensés d'images, les propriétaires de ressources doivent mettre à jour leurs stratégies avec un condensé d'image chaque fois qu'ils autorisent une nouvelle image. En utilisant les signatures d'image, la stratégie 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 référencer une clé de signature d'image de confiance que de mettre à jour une liste de nouvelles valeurs de condensé 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 de condensé d'image précédente, car les limites de confiance restent les mêmes. Dans l'approche de signature du conteneur, le propriétaire de la ressource autorise une clé de validation en spécifiant l'empreinte de la clé publique de confiance dans la stratégie WIP, et la vérification d'autorisation est effectuée par le service Attestation Verifier et WIP. Le service Attestation Verifier Service 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 revendiquée par le service est autorisée par la stratégie.

Sécurité renforcée:l'utilisation de signatures d'images de conteneurs permet de déléguer une certaine confiance au signataire de l'image. En spécifiant l'empreinte de la clé publique d'un signataire de confiance dans la règle d'attestation, le propriétaire de la ressource autorise ce signataire à approuver les images de conteneurs qui répondent à une règle. Le service Attestation Verifier Service vérifie que la signature est associée à la charge de travail en cours d'exécution, et la stratégie vérifie que la clé publique qui a créé la signature est autorisée par la stratégie. Grâce à cette couche d'indirection supplémentaire fournie par la signature d'image, les garanties de sécurité renforcées de Confidential Space sont maintenues.

La seule différence entre ces approches est que la seconde utilise une couche d'indirection supplémentaire dans laquelle les images de charge de travail sont autorisées à l'aide d'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 aux ressources protégées:

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

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

Prérequis

Terminer l'atelier de programmation sur 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 le cosignage Sigstore
Connaissances de base sur Google Compute Engine ( codelab), les Confidential VMs, les conteneurs et les dépôts distants
Connaissances de base sur Cloud KMS ( codelab)
Vous disposez de connaissances de base sur les comptes de service, la fédération d'identité de charge de travail et les conditions d'attributs.
Vous disposez de 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 des ressources, qui seront responsables des tâches suivantes:

Configurer les ressources requises avec des exemples de données
Auditer le code de la charge de travail
Utilisation de cosign pour signer l'image de la charge de travail.
Importer la signature dans un dépôt
Configurer une stratégie WIP pour protéger les données des clients

Secundus Bank en sera l'auteur et l'exploitant, et sera responsable des opérations suivantes:

Configurer les ressources requises pour stocker le résultat
Écrire le code de la charge de travail
Publication de l'image de la charge de travail.
Exécuter la charge de travail dans un espace confidentiel avec prise en charge des images de conteneur signées

La Secundus Bank développera et publiera une charge de travail qui interrogera les données client stockées dans un bucket Cloud Storage appartenant à la Primus Bank. La Primus Bank effectuera un audit de la charge de travail, signera l'image de conteneur et configurera des règles TEC pour permettre aux charges de travail approuvées d'accéder à ses donné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 d'un espace confidentiel

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, vous pouvez utiliser export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' 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 (WIP) 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 Attestation Verifier.
$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 permettant de chiffrer les données stockées dans $PRIMUS_INPUT_STORAGE_BUCKET

Ressources pour la découverte de cet atelier de programmation:

$PRIMUS_COSIGN_REPOSITORY: Artifact Registry dans lequel stocker les signatures d'image de charge de travail
$PRIMUS_SIGNING_KEY: clé KMS permettant de signer l'image de charge de travail par l'auditeur ou les collaborateurs en charge des données (par exemple, Primus Bank dans ce cas).

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

$SECUNDUS_ARTIFACT_REGISTRY: registre d'artefacts dans lequel 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 Confidential VM 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 importerons ces données dans $PRIMUS_INPUT_STORAGE_BUCKET et créerons une charge de travail qui les interrogera.

Workflow existant

Lorsque vous exécutez la charge de travail dans un espace confidentiel, 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 de l'atelier en cours. Elle offre un jeton de service Attestation Verifier avec des revendications de charge de travail et d'environnement.
Si les revendications de mesure de la charge de travail dans le jeton de service Attestation Verifier correspondent à la condition d'attribut dans l'atelier en cours, 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 du 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 compatible avec les 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 un espace confidentiel avec prise en charge des images de conteneur signées, le processus suivant a lieu, à l'aide des ressources configurées:

Confidential Space détecte toutes les signatures de conteneur associées à l'image de charge de travail en cours d'exécution et les envoie à l'outil de vérification des attestations. L'outil de vérification des attestations vérifie 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 de l'atelier en cours. Elle offre 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 de service Attestation Verifier correspondent à la condition d'attribut dans l'atelier en cours, 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 du 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

Dans le cadre de la configuration de Confidential Space, vous allez d'abord créer les ressources cloud requises dans les projets GCP de la banque Primus et Secundus. Voici les nouvelles ressources de cet atelier de programmation:

Dans le projet Primus:

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

Il n'y a pas de nouvelles ressources dans le projet Secundus. Une fois ces ressources configurées, vous allez créer un compte de service pour la charge de travail avec les rôles et les autorisations requis. Vous créerez ensuite une image de charge de travail que l'auditeur, la banque Primus, signera. La charge de travail sera ensuite autorisée par les collaborateurs des données (Primus Bank dans cet atelier de programmation) et l'opérateur de charge de travail (Secundus Bank dans le cas présent) l'exécutera.

Dans le cadre 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 pour cet atelier de programmation.

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

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 des noms de ressources mentionnés ci-dessus à l'aide de cette commande. Vous pouvez remplacer les noms de ressources à l'aide de ces variables (ex. : 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 ces instructions.

Configurer les ressources de la banque Primus

Lors 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. Lors de ces étapes, les ressources mentionnées ci-dessous seront créées:

Bucket Cloud Storage ($PRIMUS_INPUT_STORAGE_BUCKET) où stocker le fichier de données client chiffré de la banque Primus.
Clé de chiffrement ($PRIMUS_ENC_KEY) et trousseau ($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) pour 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 l'accès IAM suivant:
roles/cloudkms.cryptoKeyDecrypter pour déchiffrer les données à l'aide de la clé KMS.
objectViewer pour lire les données dans le bucket Cloud Storage.
roles/iam.workloadIdentityUser pour connecter ce compte de service au pool d'identités de charge de travail.

$ ./setup_primus_bank_resources.sh

Configurer les ressources de la banque Secundus

Lors 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. Lors des étapes ci-dessous, les ressources mentionnées seront créées:

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 les 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 dans le 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 la CLI qui compte les clients (à partir des données client de la banque Primus) à partir d'un emplacement géographique indiqué dans l'argument. Exécutez le script suivant pour créer une charge de travail dans laquelle s'effectuent les étapes suivantes:

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 de ressources requis. Voici le code de charge de travail utilisé pour cet atelier de programmation.
Créer un binaire Go et un Dockerfile pour compiler une image Docker du code de la 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.
Accorder l'autorisation de lecture à $WORKLOAD_SERVICEACCOUNT pour $SECUNDUS_ARTIFACT_REGISTRY. Cette opération est nécessaire pour que le conteneur de charge de travail puisse extraire l'image Docker de la charge de travail d'Artifact Registry.

$ ./create_workload.sh

Signer la charge de travail

Nous allons utiliser Cosign pour signer l'image de la charge de travail. Cosign stocke par défaut 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.

Dans cet exemple, nous allons utiliser Artifact Registry. Vous pouvez également choisir d'autres registres basés sur OCI, tels que Docker Hub et AWS CodeArtifact, en fonction de 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=us

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=global

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

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 y stocker des signatures.

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

Accordez le rôle Lecteur sur le dépôt $PRIMUS_COSIGN_REPOSITORY au compte de service $WORKLOAD_SERVICEACCOUNT. Cela permet à Confidential Space de découvrir toutes 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 exigeons que Cosign ne signe la signature qu'avec une paire de clés. La signature sans clé de 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 service de gestion des clés).

Générez une paire de clés dans Cosign si vous n'en avez pas. Pour en savoir plus, consultez la section Signature avec des clés autogérées.

// 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 ce qui précède, remplacez <provider>://<key> avec 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. Effectuer un encodage base64 non rempli 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 en y associant la clé publique exportée et les algorithmes de signature.

$ 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, suivez le format d'URI spécifique indiqué sur la page Compatibilité avec Sigstore KMS. Lorsque vous faites référence à une clé générée par Cosign, utilisez plutôt cosign.key.
$IMAGE_REFERENCE [OBLIGATOIRE] spécifie l'image de conteneur à signer. Le format de IMAGE_REFERENCE peut être identifié par un condensé de tag ou 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 [OBLIGATOIRE] 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 accepte UNIQUEMENT 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

Cosigner importera automatiquement les signatures dans le COSIGN_REPOSITORY spécifié.

4. Autoriser et exécuter la charge de travail

Autoriser la charge de travail

Lors de cette étape, nous allons configurer le fournisseur d'identité de charge de travail dans le pool d'identités de charge de travail ($PRIMUS_WORKLOAD_IDENTITY_POOL). Des conditions d'attribut sont configurées pour l'identité de la 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 stratégie WIP avec le condensé 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

Lors de cette étape, nous exécuterons la charge de travail sur des Confidential VMs. 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 "tee-cmd" du drapeau. La charge de travail est codée pour publier son résultat dans $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"

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 devrait être 3, car il s'agit du 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. Lors 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 d'artefacts Primus Bank qui contient les signatures d'image ($PRIMUS_COSIGN_REPOSITORY).
Pool d'identités de charge de travail Primus Bank ($PRIMUS_WORKLOAD_IDENTITY_POOL).
Compte de service de charge de travail de Secundus Bank ($WORKLOAD_SERVICEACCOUNT).
Instance de charge de travail Compute Engine.
Bucket de stockage des résultats de la banque Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).
Artifact Registry de Secundus Bank ($SECUNDUS_ARTIFACT_REGISTRY)

// run the clean up script to delete the resources created as part of this codelab.
$ ./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: cette option planifie la suppression du projet.

Félicitations

Félicitations, vous avez terminé l'atelier de programmation.

Vous avez appris à exploiter 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...