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. Prise en charge des images de conteneur signées, qui permet d'authentifier un conteneur à l'aide d'une clé publique attestée au lieu de spécifier un récapitulatif d'image dans la règle du pool d'identités de charge de travail (WIP).

Modifications apportées à la prise en charge des images de conteneur signées dans Confidential Space:

Amélioration de l'usabilité: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 qui autorisent une image.

Lorsque vous utilisez directement des condensés d'images, les propriétaires de ressources doivent mettre à jour leurs règles avec un condensé d'images 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 approuvée que de mettre à jour une liste de nouvelles valeurs de récapitulatif d'image.

Pas de régression de la sécurité:cette approche de signature de conteneur n'entraîne aucune régression de la sécurité par rapport à l'approche précédente basée sur le récapitulatif 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 la clé publique approuvée dans la règle WIP. La vérification de l'autorisation est effectuée par le service de validation de l'attestation et le WIP. Le service de validation de l'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 déclarée par le service est autorisée par la règle.

Sécurité renforcée:l'utilisation de signatures d'images de conteneur permet de déléguer une certaine 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 à approuver les images de conteneur qui respectent une stratégie. Le service de validation des attestations 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 ayant créé la signature est autorisée par la stratégie. Ainsi, la couche d'indirection supplémentaire fournie par la signature d'image maintient les garanties de sécurité élevées de Confidential Space.

La seule différence entre ces approches est que la dernière utilise une couche supplémentaire d'indirection, 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 conteneur dans des registres OCI pour la découverte et le stockage des signatures
Configurer les ressources cloud nécessaires pour exécuter un espace confidentiel
Exécuter la charge de travail dans un espace confidentiel avec la prise en charge des images de conteneur 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é approuvée exécutée 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 la cosignature Sigstore
Connaissances de base de Google Compute Engine ( atelier de programmation), des VM Confidential, des conteneurs et des dépôts distants
Connaissances de base sur Cloud KMS ( atelier de programmation)
Connaissances de base sur les comptes de service, la fédération d'identité de charge de travail et les conditions d'attribut.
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. Elle sera responsable 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 règle de travail en cours pour protéger les données des clients

Secundus Bank est l'auteur et l'opérateur de la charge de travail. Elle est responsable des éléments suivants:

Configuration des ressources requises pour stocker le résultat.
Écrire le code de la charge de travail
Publier l'image de la charge de travail
Exécuter la charge de travail dans Confidential Space avec la prise en charge des images de conteneur signées

La banque Secundus va développer et publier une charge de travail qui interrogera les données client stockées dans un bucket de stockage cloud appartenant à la banque Primus. La Primus Bank auditera la charge de travail, signera l'image du conteneur et configurera les règles de 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 d'un espace 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 partent du principe 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 de 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: le pool d'identités de charge de travail (WIP) qui valide les revendications.
$PRIMUS_WIP_PROVIDER: fournisseur du pool d'identités de charge de travail, qui inclut la condition d'autorisation à utiliser pour les jetons signés par le service de validation des attestations.
$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.

Ressources nouvelles pour cet atelier de programmation:

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

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

$SECUNDUS_ARTIFACT_REGISTRY: le dépôt 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: balise 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 les interrogera.

Workflow existant

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

La charge de travail demande un jeton d'accès Google général pour l'$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 la charge de travail dans le jeton de service du vérificateur d'attestation correspondent à la condition d'attribut dans le WIP, il renvoie le jeton d'accès pour $PRIMUS_SERVICEACCOUNT..
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 avec prise en charge des conteneurs signés

La prise en charge des 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 produit à l'aide des ressources configurées:

Confidential Space détecte toutes les signatures de conteneur associées à l'image de la charge de travail en cours d'exécution et les envoie au vérificateur d'attestation. L'outil de validation de l'attestation 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 l'$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 de service du vérificateur d'attestation 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 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 des ressources Cloud

Lors de la configuration de l'espace confidentiel, vous devez d'abord créer les ressources cloud requises dans les projets GCP des banques Primus et Secundus. Voici les ressources nouvelles 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.

Aucune nouvelle ressource n'est disponible dans le projet Secundus. Une fois ces ressources configurées, vous créerez un compte de service pour la charge de travail avec les rôles et les 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 (la banque Primus dans cet atelier de programmation) et l'opérateur de charge de travail (la 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>

Utilisez cette commande pour définir les variables pour les noms de ressources mentionnés ci-dessus. 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 variable restants sur des valeurs basées sur votre ID de projet pour les noms de ressources.

source config_env.sh

Installez Cosign en suivant les instructions disponibles sur cette page.

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 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) pour valider les revendications en fonction des conditions d'attributs configurées dans son fournisseur.
Compte de service ($PRIMUS_SERVICEACCOUNT) associé au pool d'identités de charge de travail ($PRIMUS_WORKLOAD_IDENTITY_POOL) mentionné ci-dessus, avec les droits 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 de 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 suivantes 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 les autorisations requis. Exécutez le script suivant pour créer un compte de service de charge de travail dans le projet de 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

Au cours de 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 fourni 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.
Remplacez le code de la charge de travail par les noms des ressources requises. Voici le code de la charge de travail utilisé pour cet atelier de programmation.
Créez le binaire Go et le Dockerfile pour créer 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.
Accordez à $WORKLOAD_SERVICEACCOUNT l'autorisation de lecture pour $SECUNDUS_ARTIFACT_REGISTRY. Cela est nécessaire pour que le conteneur de la charge de travail puisse extraire l'image Docker de la charge de travail à partir d'Artifact Registry.

./create_workload.sh

Charge de travail de signature

Nous allons utiliser Cosign pour signer l'image de la 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 de signatures, vous pouvez définir la variable d'environnement COSIGN_REPOSITORY.

Nous allons ici utiliser Artifact Registry comme exemple. Vous pouvez également choisir d'autres registres basés sur l'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 des signatures.

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

Attribuez le rôle de lecteur sur le dépôt $PRIMUS_COSIGN_REPOSITORY au compte de service $WORKLOAD_SERVICEACCOUNT. Confidential Space peut ainsi détecter toutes les signatures d'images de conteneur 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. Pour notre cas d'utilisation, nous n'exigeons de Cosign que de signer avec une paire de clés. La signature sans clé de cosignature 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 la section Signer avec des clés autogérées. Nous avons ici 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 la 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 l'exemple 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 valider.

// 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 avec la clé publique exportée et les algorithmes de signature joints.

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 d'URI spécifique de la prise en charge de KMS par Sigstore. Lorsque vous faites référence à une clé générée par Cosign, utilisez cosign.key à la place.
$IMAGE_REFERENCE [OBLIGATOIRE] 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 [OBLIGATOIRE] spécifie les annotations associées à la charge utile de la signature. Pour les images de conteneur signées Confidential Space, la clé publique et les algorithmes de signature doivent être associés à la charge utile de signature.

dev.cosignproject.cosign/sigalg SEULEMENT 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 avec un 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

La signature Cosign importe automatiquement les signatures dans l'COSIGN_REPOSITORY. spécifiée.

4. Autoriser et exécuter la charge de travail

Autoriser la charge de travail

À cette étape, nous allons configurer le fournisseur d'identités 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 la charge de travail par rapport à l'empreinte de la clé publique de signature. Avec cette condition d'attribut, lorsque la banque Secundus publie une nouvelle image de charge de travail, la banque Primus audite le code de la charge de travail et signe la nouvelle image de charge de travail sans avoir à mettre à jour la stratégie en cours d'élaboration 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

Au cours de cette étape, nous allons exécuter la charge de travail sur une VM confidentielle. 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 dans $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 originaires de Seattle listées dans le fichier primus_customer_list.csv.

5. Effectuer un nettoyage

Voici le script que vous pouvez utiliser 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 de la banque Primus ($PRIMUS_SERVICEACCOUNT).
Registre des artefacts de la banque Primus contenant 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 la banque Secundus ($WORKLOAD_SERVICEACCOUNT).
Instance de calcul de la charge de travail
Bucket de stockage des résultats de la banque Secundus ($SECUNDUS_RESULT_STORAGE_BUCKET).
Registre des artefacts de la banque Secundus ($SECUNDUS_ARTIFACT_REGISTRY).
VM de charge de travail de la banque Secundus ($WORKLOAD_VM).

./cleanup.sh

Si vous avez terminé votre exploration, envisagez de 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 sera alors programmé pour être supprimé.

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 l'usabilité de Confidential Space.

Et ensuite ?

Découvrez ces ateliers de programmation similaires :