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

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

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

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

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

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

結果を保存するために必要なリソースを設定します。
ワークロードコードの作成。
ワークロードイメージの公開。
署名付きコンテナイメージのサポートを使用して 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 でワークロードを実行すると、構成されたリソースを使用して次のプロセスが行われます。

ワークロードは、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. 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 ベースのレジストリを選択することもできます。

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}

ワークロードイメージの署名用に 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}

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 が鍵ペアで署名することのみを要求します。この署名付きコンテナイメージ機能では、Cosign キーレス署名はサポートされていません。

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

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

鍵ペアをまだ生成していない場合は、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 の鍵パスを参照します。

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

// 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 署名は、指定された 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 をご覧ください。