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

1. 概要

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

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

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

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

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

強力なセキュリティ: コンテナイメージの署名を使用すると、イメージ署名者に一定の信頼を委任できます。証明書ポリシーで信頼できる署名者の公開鍵フィンガープリントを指定することで、リソースオーナーは、どのコンテナイメージがポリシーを満たしているかについて署名者が推奨事項を作成することを承認します。Attestation Verifier Service は、署名が実行中のワークロードに関連付けられていることを検証します。ポリシーは、署名を作成した公開鍵がポリシーによって承認されていることを確認します。これにより、イメージ署名が提供する間接参照のレイヤが追加され、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 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 銀行が所有する 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: 監査担当者/データ共同編集者（この場合は primus bank など）がワークロードイメージの署名に使用する KMS 鍵。

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 Bank がワークロードイメージに署名します。ワークロードはデータコラボレーター（この Codelab では Primus Bank）によって承認され、ワークロードオペレーター（この場合は Secundus Bank）がワークロードを実行します。

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 Bank に必要なクラウドリソースを設定します。次のスクリプトを実行して、Primus Bank のリソースを設定します。これらの手順の一環として、次のリソースが作成されます。

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

./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 で証明書トークンを取得する
Cloud Logging にログを書き込むための logging.logWriter。
$PRIMUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取るための objectViewer。
objectAdmin: ワークロードの結果を $SECUNDUS_RESULT_STORAGE_BUCKET Cloud Storage バケットに書き込みます。

./create_workload_serviceaccount.sh

ワークロードを作成する

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

Secundus 銀行が所有する Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）を作成します。
必要なリソース名でワークロードコードを更新します。この Codelab で使用するワークロードコードはこちらです。
Go バイナリをビルドし、ワークロードコードの Docker イメージをビルドするための Dockerfile を作成します。この Codelab で使用する Dockerfile はこちらです。
Secundus 銀行が所有する Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）に Docker イメージをビルドして公開します。
$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=${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 で鍵のペアを生成します。詳細については、セルフマネージド鍵を使用した署名をご覧ください。ここでは、鍵ペアを生成してワークロードに署名する 2 つの方法（ローカルと 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 sign は、指定された 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 Bank の入力ストレージバケット（$PRIMUS_INPUT_STORAGE_BUCKET）。
Primus 銀行サービスアカウント（$PRIMUS_SERVICEACCOUNT）。
イメージ署名（$PRIMUS_COSIGN_REPOSITORY）を保持する Primus Bank アーティファクトレジストリ。
Primus Bank ワークロード ID プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）。
Secundus Bank のワークロードサービスアカウント（$WORKLOAD_SERVICEACCOUNT）。
ワークロードコンピューティングインスタンス。
Secundus Bank の結果ストレージバケット（$SECUNDUS_RESULT_STORAGE_BUCKET）。
Secundus Bank のアーティファクトレジストリ（$SECUNDUS_ARTIFACT_REGISTRY）。
Secundus Bank のワークロード VM（$WORKLOAD_VM）。

./cleanup.sh

確認が終わったら、プロジェクトの削除をご検討ください。

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

完了

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

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

次のステップ

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