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

1. 概要

この Codelab は、Confidential Space Codelab を基盤としています。署名付きコンテナ イメージのサポートにより、Workload Identity プール(WIP)ポリシーでイメージ ダイジェストを指定する代わりに、証明書付き公開鍵を使用してコンテナを認証できるようになりました。

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

使いやすさの向上: 署名付きコンテナ イメージ機能の導入により、ワークロード イメージ ダイジェスト アプローチからコンテナ署名アプローチに移行し、イメージを承認するコラボレータや監査担当者をサポートできるようになりました。

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

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

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

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

学習内容

この Codelab では、コンテナ イメージ シグネチャを使用して、保護されたリソースへのアクセスを承認する方法について学習します。

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

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

必要なもの

署名付きコンテナ イメージを使用する Confidential Space に関連するロール

この Codelab では、Primus Bank が監査担当者であり、リソース オーナーになります。Primus Bank は、次の責任を負います。

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

Secundus Bank はワークロードの作成者とオペレーターであり、次の責任を負います。

  1. 結果を保存するために必要なリソースを設定します。
  2. ワークロード コードの作成。
  3. ワークロード イメージの公開。
  4. 署名付きコンテナ イメージのサポートを使用して Confidential Space でワークロードを実行する。

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

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

この Codelab では、GCP プロジェクトに適した値に設定する必要がある変数をいくつか参照します。この Codelab のコマンドは、これらの変数が設定されていることを前提としています。(たとえば、export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' を使用して、Primus 銀行の入力ストレージ バケットの名前を設定できます)。resource-names の変数が設定されていない場合、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 でワークロードを実行すると、構成されたリソースを使用して次のプロセスが行われます。

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

署名付きコンテナをサポートする新しいワークフロー

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

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

2. Cloud リソースを設定する

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

Primus プロジェクトで、次の操作を行います。

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

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

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

始める前に

  • 次のコマンドを使用して このリポジトリのクローンを作成し、この Codelab で使用する必要なスクリプトを取得します。
git clone https://github.com/GoogleCloudPlatform/confidential-space
  • この Codelab のディレクトリを変更します。
cd confidential-space/codelabs/signed_container_codelab/scripts
  • 以下のように、必要なプロジェクトが設定されていることを確認します。
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 銀行に必要なクラウド リソースを設定します。次のスクリプトを実行して、Primus 銀行のリソースを設定します。この手順の一環として、次のリソースが作成されます。

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

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

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

  • Secundus 銀行によるワークロード実行の結果を保存する Cloud Storage バケット($SECUNDUS_RESULT_STORAGE_BUCKET)。
./setup_secundus_bank_resources.sh

3. ワークロードを作成して署名する

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

次に、必要なロールと権限を持つワークロードのサービス アカウントを作成します。次のスクリプトを実行して、Secundus 銀行プロジェクトにワークロード サービス アカウントを作成します。このサービス アカウントは、ワークロードを実行する 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 で使用するワークロードは、引数で指定された地理的位置の顧客(Primus 銀行の顧客データから)をカウントする、シンプルな CLI ベースの Go アプリです。次のスクリプトを実行して、次の手順が実行されるワークロードを作成します。

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

ワークロードに署名する

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

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

  1. Artifact Registry Docker リポジトリを作成します。
gcloud config set project $PRIMUS_PROJECT_ID
gcloud artifacts repositories create $PRIMUS_COSIGN_REPOSITORY \
  --repository-format=docker --location=${PRIMUS_PROJECT_REPOSITORY_REGION}
  1. ワークロード イメージの署名用に KMS でキーリングと鍵を作成します。
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}
  1. Artifact Registry の場合は、$LOCATION/$PROJECT/$REPOSITORY/$IMAGE_NAME などの完全なイメージ名が必要です。任意のコンテナ イメージをリポジトリにアップロードして、署名を保存できます。
export COSIGN_REPOSITORY=us-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_COSIGN_REPOSITORY}/demo
  1. $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 が鍵ペアで署名することのみを要求します。この署名付きコンテナ イメージ機能では、Cosign キーレス署名はサポートされていません。

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

  1. Cosign によって生成されたローカル鍵ペアで署名します。
  2. 他の場所(KMS など)に保存されている鍵ペアで署名します。
  1. 鍵ペアをまだ生成していない場合は、Cosign で鍵ペアを生成します。詳細については、セルフマネージド鍵による署名をご覧ください。ここでは、鍵ペアを生成してワークロードに署名する方法(ローカルと KMS プロバイダを使用)の両方を指定しました。これらの方法のいずれかを使用して、ワークロード コンテナに署名してください。
// 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 の鍵パスを参照します。
  1. 検証用の公開鍵を取得します。
// 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
  1. Cosign を使用してワークロードに署名します。公開鍵にパディングなしの Base64 エンコードを実行します。
PUB=$(cat pub.pem | openssl base64)
// Remove spaces and trailing "=" signs.
PUB=$(echo $PUB | tr -d '[:space:]' | sed 's/[=]*$//')
  1. エクスポートされた公開鍵と署名アルゴリズムを添付して、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 で生成された鍵ペアのデフォルトの署名アルゴリズムにもなります。
  1. 署名を Docker リポジトリにアップロードする

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

4. ワークロードを承認して実行する

ワークロードを承認する

このステップでは、Workload Identity プール($PRIMUS_WORKLOAD_IDENTITY_POOL)の下に Workload Identity プロバイダを設定します。以下に示すように、Workload Identity に属性条件が構成されています。条件の 1 つは、ワークロード イメージ署名のフィンガープリントを署名公開鍵のフィンガープリントと照合することです。この属性条件を使用すると、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 VM でワークロードを実行します。必要な TEE 引数は、メタデータ フラグを使用して渡されます。ワークロード コンテナの引数は、フラグの「tee-cmd」部分を使用して渡されます。ワークロードは、結果を $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"

結果を表示

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

gcloud config set project $SECUNDUS_PROJECT_ID
gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result

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

5. クリーンアップ

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

  • Primus 銀行のストレージ バケット($PRIMUS_INPUT_STORAGE_BUCKET)を入力します。
  • Primus 銀行のサービス アカウント($PRIMUS_SERVICEACCOUNT)。
  • イメージ署名を保持する Primus Bank アーティファクト レジストリ($PRIMUS_COSIGN_REPOSITORY)。
  • Primus Bank ワークロード ID プール($PRIMUS_WORKLOAD_IDENTITY_POOL)。
  • Secundus Bank のワークロード サービス アカウント($WORKLOAD_SERVICEACCOUNT)。
  • ワークロード コンピューティング インスタンス。
  • Secundus Bank の結果ストレージ バケット($SECUNDUS_RESULT_STORAGE_BUCKET)。
  • Secundus Bank の Artifact Registry($SECUNDUS_ARTIFACT_REGISTRY)。
  • Secundus Bank のワークロード VM($WORKLOAD_VM)。
./cleanup.sh

確認が完了したら、プロジェクトの削除を検討してください。

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

完了

お疲れさまでした。これでこの Codelab は終了です。

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

次のステップ

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

参考資料