このページは Cloud Translation API によって翻訳されました。

Codelab の署名付きコンテナイメージ

1. 概要

この Codelab は、Confidential Space Codelab をベースにしています。Workload Identity プール（WIP）ポリシーでイメージダイジェストを指定する代わりに、証明済みの公開鍵を使用してコンテナを認証するオプションがある場合は、署名付きコンテナイメージがサポートされます。

Confidential Space での署名付きコンテナイメージのサポートの変更点

ユーザビリティの向上: 署名付きコンテナイメージ機能の導入により、イメージを承認する共同編集者や監査者が、ワークロードイメージダイジェストアプローチからコンテナ署名アプローチに移行できるようになりました。

イメージダイジェストを直接使用する場合、リソースオーナーは新しいイメージを承認するたびに、イメージダイジェストでポリシーを更新する必要があります。イメージ署名を使用すると、ポリシーに公開鍵のフィンガープリントが含まれます。このフィンガープリントに対応する秘密鍵が共同編集者や監査者が所有し、監査対象イメージへの署名に使用されます。
一部のセキュリティモデルでは、新しいイメージダイジェスト値のリストを更新するよりも、信頼できるイメージ署名鍵を参照するほうが便利です。

セキュリティの回帰なし: このコンテナシグネチャアプローチでは信頼境界が変わらないため、以前のイメージダイジェストアプローチよりもセキュリティが低下することはありません。コンテナ署名アプローチでは、リソースオーナーが信頼できる公開鍵のフィンガープリントを WIP ポリシーに指定して検証鍵を承認し、認証検証サービスと WIP によって認証チェックが実行されます。証明書検証サービスは、署名が実行中のワークロードに関連付けられていることを確認し、WIP ポリシーでは、サービスによってアサートされた公開鍵がポリシーによって承認されていることを確認します。

強力なセキュリティ: コンテナイメージの署名を使用すると、イメージ署名者にある程度の信頼を委任できます。信頼できる署名者の公開鍵フィンガープリントを証明書ポリシーに指定することで、リソース所有者は、ポリシーに適合するコンテナイメージについて、その署名者に承認を与えることができます。証明書検証サービスは、署名が実行中のワークロードに関連付けられていることを確認し、ポリシーは署名を作成した公開鍵がポリシーによって承認されていることを確認します。これにより、イメージ署名で提供される間接的な追加レイヤにより、Confidential Space の強力なセキュリティ保証が維持されます。

2 つのアプローチの唯一の違いは、後者の方法では、ワークロードイメージが署名鍵で認証される追加の間接的なレイヤを使用する点です。信頼境界は変わらないため、これによって新たなセキュリティの脆弱性が生じることはありません。

学習内容

この Codelab では、コンテナイメージの署名を使用して、保護されたリソースへのアクセスを承認する方法を学びます。

cosign を使用して監査対象コンテナイメージに署名する方法
署名の検出と保存のためにコンテナイメージの署名を OCI レジストリにアップロードする方法
Confidential Space の実行に必要なクラウドリソースを構成する方法
署名付きコンテナイメージのサポートを使用して Confidential Space でワークロードを実行する方法

この Codelab では、Confidential Space を使用して、Google Compute Engine で実行されている信頼できる鍵で署名されたコンテナイメージに対するリモート認証を行う方法について説明します。

必要なもの

Confidential Space Codelab を修了していること
Google Cloud Platform プロジェクト
ブラウザ（Chrome や Firefox など）
Linux の標準的なテキストエディタ（Vim、Emacs、nano など）の使用経験
Sigstore Cosign に関する基本的な知識
Google Compute Engine（codelab）、Confidential VM、コンテナ、リモートリポジトリに関する基本的な知識
Cloud KMS に関する基本的な知識（codelab）
サービスアカウント、Workload Identity 連携、属性条件に関する基本的な知識。
Artifact Registry に関する基本的な知識
デジタル署名に関する基本的な知識

署名付きコンテナイメージのある Confidential Space に関係するロール

この Codelab では、Primus Bank が監査担当者兼リソースオーナーとして、以下の処理を担当します。

サンプルデータを使用して必要なリソースを設定する。
ワークロードコードを監査する。
cosign を使用してワークロードイメージに署名します。
署名をリポジトリにアップロードする。
顧客データを保護するため WIP ポリシーを設定しています。

Secundus Bank がワークロードの作成者およびオペレーターとして、以下の事項に責任を負います。

結果を保存するために必要なリソースを設定する。
ワークロードコードの記述。
ワークロードイメージの公開。
署名付きのコンテナイメージをサポートする Confidential Space でワークロードを実行する。

Secundus Bank は、Primus Bank が所有するクラウドストレージバケットに保存されている顧客データをクエリするワークロードを開発し、公開します。Primus Bank はワークロードを監査し、コンテナイメージに署名して、承認されたワークロードによるデータへのアクセスを許可する WIP ポリシーを構成します。このワークロードの実行結果は、Secundus bank が所有する Cloud Storage バケットに保存されます。

Confidential Space の設定に関連するリソース

この Codelab では、GCP プロジェクトに適した値に設定する必要があるさまざまな変数を参照します。この Codelab のコマンドでは、これらの変数が設定されていることを前提としています。（たとえば、export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' を使用すると、Primus 銀行の入力ストレージバケットの名前を設定できます）。リソース名の変数が設定されていない場合は、GCP プロジェクト ID に基づいて生成されます。

Primus プロジェクトで以下の設定を行います。

$PRIMUS_INPUT_STORAGE_BUCKET: 顧客データファイルを保存するバケット。
$PRIMUS_WORKLOAD_IDENTITY_POOL: クレームを検証する Workload Identity プール（WIP）。
$PRIMUS_WIP_PROVIDER: 構成証明検証サービスによって署名されたトークンに使用する認可条件を含む Workload Identity プールプロバイダ。
$PRIMUS_SERVICEACCOUNT: $PRIMUS_WORKLOAD_IDENTITY_POOL が保護されたリソースにアクセスするために使用するサービスアカウント。このステップでは、$PRIMUS_INPUT_STORAGE_BUCKET バケットに保存されている顧客データを表示する権限があります。
$PRIMUS_ENC_KEY: $PRIMUS_INPUT_STORAGE_BUCKET に保存されているデータの暗号化に使用される KMS 鍵。

この Codelab の新しいリソース:

$PRIMUS_COSIGN_REPOSITORY: ワークロードイメージの署名を保存する Artifact Registry。
$PRIMUS_SIGNING_KEY: 監査者/データ共同編集者がワークロードイメージに署名するために使用される KMS 鍵（この場合は primus bank など）。

Secundus プロジェクトで次の構成を行います。

$SECUNDUS_ARTIFACT_REGISTRY: ワークロードの Docker イメージが push される Artifact Registry。
$WORKLOAD_IMAGE_NAME: ワークロード Docker イメージの名前。
$WORKLOAD_IMAGE_TAG: ワークロードの Docker イメージのタグ。
$WORKLOAD_SERVICEACCOUNT: ワークロードを実行する Confidential VM にアクセスする権限を持つサービスアカウント。
$SECUNDUS_RESULT_BUCKET: ワークロードの結果を保存するバケット。

その他のリソース

primus_customer_list.csv には顧客データが含まれています。このデータを $PRIMUS_INPUT_STORAGE_BUCKET にアップロードし、このデータに対してクエリを実行するワークロードを作成します。

既存のワークフロー

Confidential Space でワークロードを実行すると、構成されたリソースを使用して、次のプロセスが行われます。

ワークロードが WIP から $PRIMUS_SERVICEACCOUNT の一般的な Google アクセストークンをリクエストします。ワークロードと環境のクレームを含む証明書検証サービストークンを提供します。
証明書検証サービストークン内のワークロード測定クレームが WIP の属性条件と一致する場合は、$PRIMUS_SERVICEACCOUNT. のアクセストークンが返されます。
ワークロードは、$PRIMUS_SERVICEACCOUNT に関連付けられたサービスアカウントのアクセストークンを使用して、$PRIMUS_INPUT_STORAGE_BUCKET バケット内の顧客データにアクセスします。
ワークロードはそのデータに対してオペレーションを実行します。
ワークロードは、$WORKLOAD_SERVICEACCOUNT サービスアカウントを使用して、そのオペレーションの結果を $SECUNDUS_RESULT_STORAGE_BUCKET バケットに書き込みます。

署名付きコンテナのサポートを使用した新しいワークフロー

以下でハイライト表示されているように、署名付きコンテナサポートは既存のワークフローに統合されます。署名付きコンテナイメージのサポートを使用して Confidential Space でワークロードを実行すると、構成されたリソースを使用して、次のプロセスが行われます。

Confidential Space は、現在実行中のワークロードイメージに関連するコンテナ署名を検出して、証明書検証者に送信します。証明書検証機能は署名を検証し、有効な署名があれば証明書クレームに追加します。
ワークロードが WIP から $PRIMUS_SERVICEACCOUNT の一般的な Google アクセストークンをリクエストします。ワークロードと環境のクレームを含む証明書検証サービストークンを提供します。
証明書検証サービストークン内のコンテナ署名クレームが WIP の属性条件と一致する場合、$PRIMUS_SERVICEACCOUNT のアクセストークンが返されます。
ワークロードは、$PRIMUS_SERVICEACCOUNT に関連付けられたサービスアカウントのアクセストークンを使用して、$PRIMUS_INPUT_STORAGE_BUCKET バケット内の顧客データにアクセスします。
ワークロードはそのデータに対してオペレーションを実行します。
ワークロードは、$WORKLOAD_SERVICEACCOUNT を使用して、そのオペレーションの結果を $SECUNDUS_RESULT_STORAGE_BUCKET バケットに書き込みます。

2. クラウドリソースの設定

Confidential Space の設定の一環として、まず Primus と Secundus 銀行の GCP プロジェクトに必要なクラウドリソースを作成します。この Codelab の新しいリソースは次のとおりです。

Primus プロジェクトの内容:

コードを監査した後、Secundus ワークロードの署名に使用される KMS 署名鍵。
Cosign 署名を保存する Artifact Registry リポジトリ。

Secundus プロジェクトに新しいリソースはありません。これらのリソースを設定したら、必要なロールと権限を持つワークロードのサービスアカウントを作成します。次に、ワークロードイメージを作成し、監査者の Primus bank がワークロードイメージに署名します。その後、データコラボレーター（この Codelab では Primus bank）がワークロードを承認し、ワークロードオペレーター（この場合は Secundus Bank）がワークロードを実行します。

Confidential Space の設定の一環として、Primus と Secundus の GCP プロジェクトに必要なクラウドリソースを作成します。

始める前に

以下のコマンドを使用してこのリポジトリのクローンを作成し、この Codelab に必要なスクリプトを取得します。

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

次のように必要なプロジェクトが設定されていることを確認します。

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

次のコマンドを使用して、上記のリソース名の変数を設定します。リソース名は、これらの変数（例: export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket'）を使用してオーバーライドできます。
次のスクリプトを実行して、残りの変数名を、リソース名のプロジェクト ID に基づく値に設定します。

$ source config_env.sh

こちらの手順に沿って cosign をインストールします。

Primus 銀行のリソースを設定する

このステップでは、Primus Bank に必要なクラウドリソースを設定します。次のスクリプトを実行して、Primus Bank のリソースを設定します。この手順の一環として、以下のリソースが作成されます。

Primus 銀行の暗号化された顧客データファイルを保存するための Cloud Storage バケット（$PRIMUS_INPUT_STORAGE_BUCKET）。
Primus 銀行のデータファイルを暗号化するための KMS の暗号鍵（$PRIMUS_ENC_KEY）とキーリング（$PRIMUS_ENC_KEYRING）。
プロバイダで構成された属性条件に基づいてクレームを検証する Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）。
次の IAM アクセス権を持つ上記の Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）に接続されているサービスアカウント（$PRIMUS_SERVICEACCOUNT）。
roles/cloudkms.cryptoKeyDecrypter: KMS 鍵を使用してデータを復号します。
Cloud Storage バケットからデータを読み取るための objectViewer。
roles/iam.workloadIdentityUser: このサービスアカウントを Workload Identity プールに接続するためのものです。

$ ./setup_primus_bank_resources.sh

Secundus 銀行のリソースを設定する

このステップの一環として、Secundus bank に必要なクラウドリソースを設定します。次のスクリプトを実行して、Secundus bank のリソースを設定します。この手順の一環として、次のリソースが作成されます。

Secundus bank によるワークロード実行の結果を保存する Cloud Storage バケット（$SECUNDUS_RESULT_STORAGE_BUCKET）。

$ ./setup_secundus_bank_resources.sh

3. ワークロードの作成と署名

ワークロードサービスアカウントを作成する

次に、必要なロールと権限を持つワークロードのサービスアカウントを作成します。次のスクリプトを実行して、Secundus bank プロジェクトにワークロードサービスアカウントを作成します。このサービスアカウントは、ワークロードを実行する VM によって使用されます。

このワークロードサービスアカウント（$WORKLOAD_SERVICEACCOUNT）には、次のロールがあります。
confidentialcomputing.workloadUser: 証明書トークンを取得する
logging.logWriter: Cloud Logging にログを書き込む。
objectViewer で $PRIMUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取る
objectAdmin - ワークロードの結果を $SECUNDUS_RESULT_STORAGE_BUCKET Cloud Storage バケットに書き込みます。

$ ./create_workload_serviceaccount.sh

ワークロードを作成

このステップの一環として、ワークロードの Docker イメージを作成します。この Codelab で使用するワークロードは CLI ベースのシンプルな Go アプリで、引数として指定された地理的位置から顧客を（Primus Bank の顧客データから）カウントします。次のスクリプトを実行して、以下のステップを実行するワークロードを作成します。

Secundus bank が所有する Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）を作成します。
必要なリソース名でワークロードコードを更新します。こちらが、この Codelab で使用するワークロードコードです。
Go バイナリをビルドし、ワークロードコードの Docker イメージをビルドするための Dockerfile を作成します。この Codelab に使用した Dockerfile はこちらです。
Docker イメージをビルドして、Secundus bank が所有する Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）に公開します。
$SECUNDUS_ARTIFACT_REGISTRY に対する読み取り権限を $WORKLOAD_SERVICEACCOUNT に付与します。これは、ワークロードコンテナが Artifact Registry からワークロード Docker イメージを pull するために必要です。

$ ./create_workload.sh

ワークロードに署名

Cosign を使用してワークロードイメージに署名します。Cosign はデフォルトで、署名するイメージと同じリポジトリに署名を保存します。署名に別のリポジトリを指定するには、COSIGN_REPOSITORY 環境変数を設定します。

ここでは、例として Artifact Registry を使用します。必要に応じて、Docker Hub、AWS CodeArtifact など、他の OCI ベースのレジストリを選択することもできます。

Artifact Registry Docker リポジトリを作成する。

$ gcloud config set project $PRIMUS_PROJECT_ID

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

ワークロードイメージに署名するためのキーリングと鍵を KMS で作成します。

$ 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

Artifact Registry では、$LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME などの完全なイメージ名が想定されます。任意のコンテナイメージをリポジトリにアップロードして署名を保存できます。

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

$PRIMUS_COSIGN_REPOSITORY リポジトリの閲覧者ロールを $WORKLOAD_SERVICEACCOUNT サービスアカウントに付与します。これにより、Confidential Space は $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 は複数の署名機能を備えた強力なツールです。このユースケースでは、鍵ペアによる署名にのみ Cosign が必要です。キーなし署名は、この署名付きのコンテナイメージ機能ではサポートされていません。

鍵ペアで署名する場合は、次の 2 つの方法があります。

Cosign によって生成されたローカル鍵ペアで署名します。
他の場所（KMS など）に保存されている鍵ペアで署名する。

鍵ペアがない場合は、Cosign で生成します。詳しくは、自己管理鍵を使用した署名をご覧ください。

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

上記の <provider>://<key> を参加者: gcpkms://projects/$PRIMUS_PROJECT_ID/locations/global/keyRings/$PRIMUS_SIGNING_KEYRING/cryptoKeys/$PRIMUS_SIGNING_KEY/cryptoKeyVersions/$PRIMUS_SIGNING_KEYVERSION さん

<provider>: 使用している KMS ソリューションのこと
<key>: KMS の鍵パス

検証用の公開鍵を取得します。

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

Cosign を使用してワークロードに署名します。公開鍵にパディングなしの base64 エンコードを実行します

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

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

エクスポートされた公開鍵と署名アルゴリズムをアタッチした Cosign を使用して、ワークロードに署名します。

$ 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（必須）: 使用する署名鍵を指定します。KMS プロバイダが管理する鍵を参照する場合は、Sigstore KMS サポートの URI 形式に従ってください。Cosign によって生成された鍵を参照する場合は、代わりに cosign.key を使用します。
$IMAGE_REFERENCE（必須）は、署名するコンテナイメージを指定します。IMAGE_REFERENCE の形式は、タグまたはイメージのダイジェストで識別できます。例: 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 [必須] は、署名ペイロードに添付されたアノテーションを指定します。Confidential Space で署名されたコンテナイメージの場合、署名ペイロードに公開鍵と署名アルゴリズムを関連付ける必要があります。

dev.cosignproject.cosign/sigalg のみ、次の 3 つの値を指定できます。
RSASSA_PSS_SHA256: SHA256 ダイジェストを使用した PSS パディングありの RSASSA アルゴリズム。
RSASSA_PKCS1V15_SHA256: SHA256 ダイジェストを使用した PKCS#1 v1.5 パディング付き RSASSA アルゴリズム。
ECDSA_P256_SHA256: P-256 曲線の ECDSA（SHA256 ダイジェストを使用）。これは、Cosign で生成された鍵ペアのデフォルトの署名アルゴリズムでもあります。

Docker リポジトリに署名をアップロードする

Cosign Sign は、指定された COSIGN_REPOSITORY に署名を自動的にアップロードします。

4. ワークロードの承認と実行

ワークロードの承認

この手順の一環として、Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）に Workload Identity プロバイダを設定します。次に示すように、Workload Identity には属性条件が構成されています。条件の一つは、ワークロードイメージの署名のフィンガープリントを、署名公開鍵のフィンガープリントと比較して検証することです。この属性条件を使用すると、Secundus Bank が新しいワークロードイメージをリリースすると、Primus Bank がワークロードコードを監査して新しいワークロードイメージに署名します。WIP ポリシーをイメージダイジェストで更新する必要はありません。

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

ワークロードの実行

このステップの一環として、Confidential VMs でワークロードを実行します。必須の TEE 引数は、メタデータフラグを使用して渡されます。ワークロードコンテナの引数は、「tee-cmd」を使用して渡されます部分に分割されます。ワークロードは、結果を $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"

結果を表示

Secundus プロジェクトで、ワークロードの結果を表示します。

$ gcloud config set project $SECUNDUS_PROJECT_ID

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

primus_customer_list.csv ファイルにリストされているシアトルのユーザーの数は 3 であるため、結果は 3 になります。

5. クリーンアップ

この Codelab で作成したリソースをクリーンアップするために使用できるスクリプトは、こちらにあります。このクリーンアップの一環として、次のリソースが削除されます。

Primus 銀行の入力ストレージバケット（$PRIMUS_INPUT_STORAGE_BUCKET）。
Primus 銀行のサービスアカウント（$PRIMUS_SERVICEACCOUNT）。
イメージ署名を保持する Primus Bank Artifact Registry（$PRIMUS_COSIGN_REPOSITORY）。
Primus Bank の Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）。
Secundus Bank のワークロードサービスアカウント（$WORKLOAD_SERVICEACCOUNT）。
ワークロードコンピューティングインスタンス。
Secundus Bank の結果ストレージバケット（$SECUNDUS_RESULT_STORAGE_BUCKET）。
Secundus Bank の Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）。

// run the clean up script to delete the resources created as part of this codelab.
$ ./cleanup.sh

確認を終えた場合は、プロジェクトを削除することをおすすめします。

Cloud Platform コンソールに移動します。
シャットダウンするプロジェクトを選択し、[削除] をクリックしますプロジェクトの削除がスケジュールされます。

完了

これでこの Codelab は終了です。

署名付きのコンテナイメージの機能を活用して Confidential Space のユーザビリティを向上させる方法を学びました。

次のステップ

以下の類似の Codelab をご確認ください。