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 は、Cloud Storage バケットに保存され、Primus Bank が所有する顧客データをクエリするワークロードを開発して公開します。Primus Bank はワークロードを監査し、コンテナイメージに署名し、承認されたワークロードがデータにアクセスできるように WIP ポリシーを構成します。このワークロードの実行結果は、Secundus Bank が所有する Cloud Storage バケットに保存されます。

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

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

Primus プロジェクトで次の項目を構成します。

$PRIMUS_INPUT_STORAGE_BUCKET: 顧客データファイルを保存するバケット。
$PRIMUS_WORKLOAD_IDENTITY_POOL: クレームを検証する Workload Identity プール（WIP）。
$PRIMUS_WIP_PROVIDER: Attestation Verifier Service によって署名されたトークンに使用する承認条件を含む 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 されるアーティファクトレジストリ。
$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 アクセストークンをリクエストします。ワークロードと環境のクレームを含む Attestation Verifier Service トークンを提供します。
Attestation Verifier Service トークンのワークロード測定クレームが WIP の属性条件と一致する場合、 $PRIMUS_SERVICEACCOUNT. のアクセストークンが返されます。
ワークロードは、$PRIMUS_SERVICEACCOUNT に関連付けられたサービスアカウントのアクセストークンを使用して、$PRIMUS_INPUT_STORAGE_BUCKET バケット内の顧客データにアクセスします。
ワークロードはそのデータに対してオペレーションを実行します。
ワークロードは $WORKLOAD_SERVICEACCOUNT サービスアカウントを使用して、そのオペレーションの結果を $SECUNDUS_RESULT_STORAGE_BUCKET バケットに書き込みます。

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

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

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

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

Confidential Space の設定の一環として、まず Primus Bank と Secundus Bank の 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 Bank のリソースを設定する

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

Primus Bank の暗号化された顧客データファイルを保存する Cloud Storage バケット（$PRIMUS_INPUT_STORAGE_BUCKET）。
KMS の暗号化鍵（$PRIMUS_ENC_KEY）とキーリング（$PRIMUS_ENC_KEYRING）を使用して、Primus Bank のデータファイルを暗号化します。
プロバイダで構成された属性条件に基づいてクレームを検証する 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 Bank のリソースを設定する

このステップでは、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 は次のとおりです。
Secundus Bank が所有する Artifact Registry（$SECUNDUS_ARTIFACT_REGISTRY）に Docker イメージをビルドして公開します。
$WORKLOAD_SERVICEACCOUNT に $SECUNDUS_ARTIFACT_REGISTRY の読み取り権限を付与します。これは、ワークロードコンテナが Artifact Registry からワークロード Docker イメージを pull するために必要です。

./create_workload.sh

ワークロードに署名する

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

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

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 署名は、指定された 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 Bank サービスアカウント（$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）。
Secundus Bank のワークロード VM（$WORKLOAD_VM）。

./cleanup.sh

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

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

完了

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

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

次のステップ

以下の Codelab もご覧ください。