使用中の共有データを Confidential Space で保護する

1. 概要

Confidential Space は、安全なマルチパーティデータ共有とコラボレーションを提供し、組織がデータの機密性を維持できるようにします。つまり、組織はデータを制御し、不正アクセスから保護しながら、相互に連携できます。

Confidential Space は、機密データ（多くの場合、規制対象データ）を集約して分析することで相互に価値を得ながら、そのデータを完全に管理したい場合に役立ちます。Confidential Space では、個人を特定できる情報（PII）、保護医療情報（PHI）、知的財産、暗号シークレットなどの機密データを完全に管理しながら集約、分析することで、共同作業を行う企業は相互に価値を得ることができます。

必要なもの

Google Cloud Platform プロジェクト
Chrome や Firefox などのブラウザ
Google Compute Engine（codelab）、Confidential VM、コンテナ、リモートリポジトリに関する基本的な知識
Cloud KMS の基本的な知識（codelab）
サービスアカウント、Workload Identity 連携、属性条件に関する基本的な知識。

学習内容

Confidential Space の実行に必要なクラウドリソースを構成する方法
Confidential Space VM イメージを実行する Confidential VM でワークロードを実行する方法
ワークロードコードの属性（何）、Confidential Space 環境（どこ）、ワークロードを実行しているアカウント（誰）に基づいて、保護されたリソースへのアクセスを承認する方法。

この Codelab では、Primus Bank と Secundus Bank の間に Confidential Space を設定して、完全な顧客リストを共有することなく共通の顧客を特定します。次の作業を行います。

ステップ 1: Primus Bank と Secundus Bank に必要なクラウドリソースを設定します。これらのクラウドリソースには、Primus Bank と Secundus Bank のクラウドストレージバケット、KMS 鍵、Workload Identity プール、サービスアカウントが含まれます。Primus Bank と Secundus Bank は、顧客データを Cloud Storage バケットに保存し、Cloud Key Management Service の鍵を使用してデータを暗号化します。
ステップ 2: ワークロード VM で使用されるワークロードサービスアカウントを作成します。ワークロードのオペレーターである Secundus Bank がワークロード VM を起動します。Primus Bank がワークロードコードを作成します。
ステップ 3: 2 つの CLI コマンドを含むワークロードを作成します。1 つは指定された場所の顧客数をカウントするコマンド、もう 1 つは Primus Bank と Secundus Bank の共通の顧客を見つけるコマンドです。ワークロードは Primus Bank によって作成され、Docker イメージとしてパッケージ化されます。この Docker イメージは Artifact Registry に公開されます。
ステップ 4: ワークロードを承認します。Primus Bank は、Workload Identity プールを使用して、ワークロードを実行しているユーザーの属性、ワークロードの処理内容、ワークロードの実行場所に基づいて、顧客データにアクセスするワークロードを承認します。
ステップ 5: ワークロードが実行されると、ワークロードと環境のクレームを含む Attestation Verifier サービストークンを提供して、データコラボレーター（Primus Bank と Secundus Bank）のクラウドリソースへのアクセスをリクエストします。トークン内のワークロード測定値のクレームが、Primus Bank と Secundus Bank のワークロード ID プールの属性条件と一致する場合、それぞれのクラウドリソースにアクセスする権限を持つサービスアカウントアクセストークンが返されます。クラウドリソースには、Confidential Space 内で実行されているワークロードのみがアクセスできます。
ステップ 5（a）: 特定の地域に住む Primus Bank の顧客数をカウントする最初のワークロードを実行します。このワークロードでは、Primus Bank はデータコラボレーターとワークロード作成者になり、Confidential Space で実行されているワークロードに暗号化された顧客リストを提供します。Secundus Bank はワークロードオペレーターであり、Confidential Space でワークロードを実行します。
ステップ 5（b）: Primus Bank と Secundus Bank の共通の顧客を見つける 2 番目のワークロードを実行します。このワークロードでは、Primus Bank と Secundus Bank の両方がデータコラボレーターになります。暗号化された顧客リストは、Confidential Space で実行されているワークロードに提供されます。Secundus Bank は再びワークロードオペレーターになります。このワークロードは、共通の顧客を見つけるために Secundus Bank の暗号化された顧客リストにもアクセスする必要があるため、Secundus Bank によって承認されます。この場合、Secundus Bank は、Primus Bank のステップ 4 で説明したように、ワークロードを実行しているユーザーの属性、ワークロードの処理内容、ワークロードの実行場所に基づいて、ワークロードが顧客データにアクセスすることを承認します。

2. クラウドリソースを設定する

始める前に

次のコマンドを使用してこのリポジトリのクローンを作成し、この Codelab の一部として使用される必要なスクリプトを取得します。

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

この Codelab のディレクトリを変更します。

cd confidential-space/codelabs/bank_data_analysis_codelab/scripts

次の図に示すように、必要なプロジェクト環境変数が設定されていることを確認します。GCP プロジェクトの作成の詳細については、こちらの Codelab をご覧ください。プロジェクト ID の取得方法と、プロジェクト名やプロジェクト番号との違いについては、こちらをご覧ください。

export PRIMUS_PROJECT_ID=<GCP project id of Primus bank>
export SECUNDUS_PROJECT_ID=<GCP project id of Secundus bank>

プロジェクトに対する課金を有効にします。
両方のプロジェクトで Confidential Computing API と次の API を有効にします。

gcloud services enable \
    cloudapis.googleapis.com \
    cloudkms.googleapis.com \
    cloudresourcemanager.googleapis.com \
    cloudshell.googleapis.com \
    container.googleapis.com \
    containerregistry.googleapis.com \
    iam.googleapis.com \
    confidentialcomputing.googleapis.com

このコマンドを使用して、リソース名の変数を次のように設定します。これらの変数（export PRIMUS_INPUT_STORAGE_BUCKET='my-input-bucket' など）を使用して、リソース名をオーバーライドできます。
Primus プロジェクトの既存のクラウドリソース名を使用して、次の変数を設定できます。変数が設定されている場合、Primus プロジェクトの対応する既存のクラウドリソースが使用されます。変数が設定されていない場合、クラウドリソース名は project-name から生成され、新しいクラウドリソースは次の処理の一部として作成されます。

`$PRIMUS_INPUT_STORAGE_BUCKET`	Primus Bank の顧客データファイルを保存するバケット。
`$PRIMUS_WORKLOAD_IDENTITY_POOL`	クレームを検証する Primus Bank の Workload Identity プール（WIP）。
`$PRIMUS_WIP_PROVIDER`	Attestation Verifier Service によって署名されたトークンに使用する認可条件を含む、Primus Bank の Workload Identity プールプロバイダ。
`$PRIMUS_SERVICE_ACCOUNT`	`$PRIMUS_WORKLOAD_IDENTITY_POOL` が保護されたリソースにアクセスするために使用する Primus Bank のサービスアカウント。このステップでは、`$PRIMUS_INPUT_STORAGE_BUCKET` バケットに保存されている顧客データを表示する権限があります。
`$PRIMUS_ENC_KEY`	Primus Bank の `$PRIMUS_INPUT_STORAGE_BUCKET` に保存されているデータの暗号化に使用される KMS 鍵。
`$PRIMUS_ENC_KEYRING`	Primus Bank の暗号鍵 `$PRIMUS_ENC_KEY` の作成に使用される KMS キーリング。
`$PRIMUS_ARTIFACT_REPOSITORY`	ワークロード Docker イメージが push されるアーティファクトリポジトリ。

Secundus プロジェクトの既存のクラウドリソース名を使用して、次の変数を設定できます。変数が設定されている場合、Secundus プロジェクトの対応する既存のクラウドリソースが使用されます。変数が設定されていない場合、クラウドリソース名は project-name から生成され、新しいクラウドリソースは次のものの一部として作成されます。

`$SECUNDUS_INPUT_STORAGE_BUCKET`	Secundus Bank の顧客データファイルを保存するバケット
`$SECUNDUS_WORKLOAD_IDENTITY_POOL`	クレームを検証する Secundus Bank の Workload Identity プール（WIP）。
`$SECUNDUS_WIP_PROVIDER`	Secundus Bank の Workload Identity プールプロバイダ。Attestation Verifier Service によって署名されたトークンに使用する認可条件が含まれています。
`$SECUNDUS_SERVICE_ACCOUNT`	`$SECUNDUS_WORKLOAD_IDENTITY_POOL` が保護されたリソースにアクセスするために使用する Secundus Bank のサービスアカウント。このステップでは、`$SECUNDUS_INPUT_STORAGE_BUCKET` バケットに保存されている顧客データを表示する権限があります。
`$SECUNDUS_ENC_KEY`	Secundus Bank の `$SECUNDUS_INPUT_STORAGE_BUCKET` に保存されているデータの暗号化に使用される KMS 鍵。
`$SECUNDUS_ENC_KEYRING`	Secundus Bank の暗号鍵 `$SECUNDUS_ENV_KEY` の作成に使用される KMS キーリング。
`$SECUNDUS_RESULT_STORAGE_BUCKET`	ワークロードの結果を保存するバケット。
`$WORKLOAD_IMAGE_NAME`	ワークロードコンテナイメージ名。
`$WORKLOAD_IMAGE_TAG`	ワークロードコンテナイメージのタグ。
`$WORKLOAD_SERVICE_ACCOUNT`	ワークロードを実行する Confidential VM にアクセスする権限を持つサービスアカウント。

この Codelab では、以下に示すように、いくつかのアーティファクトを使用します。
primus_customer_list.csv: Primus Bank の顧客データを含むファイル。この Codelab で使用するサンプルファイルはこちらです。
secundus_customer_list.csv: Secundus Bank の顧客データを含むファイル。この Codelab で使用するサンプルファイルはこちらです。
これらの 2 つのプロジェクトには、次の権限が必要です。
$PRIMUS_PROJECT_ID の場合、Cloud KMS 管理者、Storage 管理者、Artifact Registry 管理者、サービスアカウント管理者、IAM Workload Identity プール管理者が必要です。
$SECUNDUS_PROJECT_ID の場合は、Compute 管理者、Storage 管理者、サービスアカウント管理者、Cloud KMS 管理者、IAM Workload Identity プール管理者、セキュリティ管理者（省略可）が必要です。
次のスクリプトを実行して、残りの変数名をリソース名のプロジェクト ID に基づく値に設定します。

source config_env.sh

Primus Bank のクラウドリソースを設定する

Primus Bank には次のクラウドリソースが必要です。次のスクリプトを実行して、Primus Bank のリソースを設定します。

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

./setup_primus_bank_resources.sh

Secundus Bank のクラウドリソースを設定する

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

Secundus Bank の暗号化された顧客データファイルを保存する Cloud Storage バケット（$SECUNDUS_INPUT_STORAGE_BUCKET）。
Secundus Bank のデータファイルを暗号化する KMS の暗号鍵（$SECUNDUS_ENC_KEY）と鍵リング（$SECUNDUS_ENC_KEYRING）。
Workload Identity プール（$SECUNDUS_WORKLOAD_IDENTITY_POOL）: プロバイダで構成された属性条件に基づいてクレームを検証します。
上記のワークロード ID プール（$SECUNDUS_WORKLOAD_IDENTITY_POOL）に関連付けられたサービスアカウント（$SECUNDUS_SERVICE_ACCOUNT）は、KMS 鍵を使用したデータの復号（roles/cloudkms.cryptoKeyDecrypter ロールを使用）、Cloud Storage バケットからのデータの読み取り（objectViewer ロールを使用）、サービスアカウントとワークロード ID プールの接続（roles/iam.workloadIdentityUser ロールを使用）を行うことができます。
Secundus Bank によるワークロード実行の結果を保存する Cloud Storage バケット（$SECUNDUS_RESULT_STORAGE_BUCKET）。

./setup_secundus_bank_resources.sh

3. ワークロードを作成する

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

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

このワークロードサービスアカウント（$WORKLOAD_SERVICE_ACCOUNT）には次のロールが付与されます。

ワークロードサービスアカウントに confidentialcomputing.workloadUser ロールを付与します。これにより、ユーザーアカウントで構成証明トークンを生成できるようになります。
ワークロードサービスアカウントに logging.logWriter ロールを付与します。これにより、Confidential Space 環境はシリアルコンソールに加えて Cloud Logging にログを書き込むことができるため、VM の終了後もログを利用できます。
$PRIMUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取るための objectViewer。
$SECUNDUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取るための objectViewer。
objectAdmin: ワークロードの結果を $SECUNDUS_RESULT_STORAGE_BUCKET Cloud Storage バケットに書き込みます。

./create_workload_service_account.sh

ワークロードを作成する

このステップでは、この Codelab で使用するワークロードの Docker イメージを作成します。ワークロードは、次の処理を行うシンプルな GoLang アプリケーションです。

指定した地域にいる顧客の数をカウントします。
それぞれのクラウドストレージバケットに保存されている顧客リストから、Primus Bank と Secundus Bank の共通の顧客を検索します。

次のスクリプトを実行して、次の手順が実行されるワークロードを作成します。

ワークロードが公開される Primus Bank が所有する Artifact Registry（$PRIMUS_ARTIFACT_REPOSITORY）を作成します。
コードを生成し、必要なリソース名で更新します。この Codelab で使用するワークロードコードは、こちらにあります。
コードをビルドして Docker イメージにパッケージ化します。対応する Dockerfile はこちらで確認できます。
Primus Bank が所有する Artifact Registry（$PRIMUS_ARTIFACT_REGISTRY）に Docker イメージを公開します。
サービスアカウントに Artifact Registry（$PRIMUS_ARTIFACT_REGISTRY）の $WORKLOAD_SERVICE_ACCOUNT 読み取り権限を付与します。

./create_workload.sh

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

ワークロードを承認する

Primus Bank は、次のリソースの属性に基づいて、ワークロードが顧客データにアクセスすることを承認したいと考えています。

内容: 確認済みのコード
場所: 安全な環境
Who: 信頼されているオペレーター

Primus は、これらの要件に基づいてアクセスポリシーを適用するために Workload Identity 連携を使用します。

Workload Identity 連携では、属性条件を指定できます。これらの条件により、Workload Identity プール（WIP）で認証できる ID が制限されます。証明書検証サービスを Workload Identity プールプロバイダとして WIP に追加して、測定値を提示し、ポリシーを適用できます。

Workload Identity プールは、クラウドリソースの設定手順の一部としてすでに作成されています。これで、Primus Bank は新しい OIDC Workload Identity プールプロバイダを作成します。指定された --attribute-condition は、ワークロードコンテナへのアクセスを承認します。この構成では、次のものが必要になります。

内容: 最新の $WORKLOAD_IMAGE_NAME が $PRIMUS_ARTIFACT_REPOSITORY リポジトリにアップロードされました。
条件: Confidential Space の信頼できる実行環境が、完全にサポートされている Confidential Space VM イメージで実行されている。
対象: Secundus Bank $WORKLOAD_SERVICE_ACCOUNT サービスアカウント。

gcloud config set project $PRIMUS_PROJECT_ID

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 &&
   assertion.submods.container.image_reference == 'us-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

Primus Bank 向けに作成された WIP と同様に、Secundus Bank は次の条件に基づいてワークロードが顧客データにアクセスすることを承認したいと考えています。

内容: ワークロード。
場所: Confidential Space 環境。
対象: ワークロードを実行しているアカウント（$WORKLOAD_SERVICE_ACCOUNT）。

Primus Bank は、イメージタグを含む image_reference クレームを使用して、アクセスを承認するかどうかを判断します。リモートリポジトリを制御しているため、データが漏洩しないイメージのみにタグ付けできます。

一方、Secundus Bank はイメージを取得するリポジトリを制御していないため、その前提を安全に立てることはできません。代わりに、ワークロードの image_digest に基づいてワークロードへのアクセスを承認することを選択します。image_reference は Primus Bank が別の画像を指すように変更できますが、image_digest は Secundus Bank が前の手順で監査した画像以外の画像を参照することはできません。

Workload Identity プールプロバイダを作成する前に、プロバイダの属性条件で使用されるワークロードコンテナイメージの image_digest を収集します。

export WORKLOAD_IMAGE_DIGEST=$(gcloud artifacts docker images describe ${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG  --format="value(image_summary.digest)" --project ${PRIMUS_PROJECT_ID})

gcloud config set project $SECUNDUS_PROJECT_ID

gcloud iam workload-identity-pools providers create-oidc $SECUNDUS_WIP_PROVIDER \
  --location="global" \
  --workload-identity-pool="$SECUNDUS_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 && 
assertion.submods.container.image_digest == '${WORKLOAD_IMAGE_DIGEST}' &&
 assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

ワークロードを実行する

このステップの一環として、Secundus Bank は Confidential Space でワークロードを実行します。このワークロードは、Primus のワークロード ID プールと Secundus のワークロード ID プールからアクセストークンを取得し、それぞれ Primus Bank と Secundus Bank の顧客データを読み取って復号します。

必要な TEE 引数は、メタデータフラグを使用して渡されます。ワークロードコンテナの引数は、フラグの「tee-cmd」部分を使用して渡されます。ワークロード実行の結果は $SECUNDUS_RESULT_STORAGE_BUCKET に公開されます。

最初のワークロードを実行する

最初のワークロードの実行の一環として、ワークロードはワークロードコンテナ引数で指定された場所から Primus Bank の顧客数をカウントします。次の図に示すように、最初のワークロードは「count-location」コマンドを実行し、結果は $SECUNDUS_RESULT_STORAGE_BUCKET/seattle-result に保存されます。

gcloud compute instances create ${WORKLOAD_VM1} \
 --project=${SECUNDUS_PROJECT_ID} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"count-location\",\"Seattle\",\"gs://${SECUNDUS_RESULT_STORAGE_BUCKET}/seattle-result\"]""

結果を表示

Secundus プロジェクトで、最初のワークロードの結果を表示します。ワークロードが実行を完了し、結果が Cloud Storage バケットで使用可能になるまで 3 ～ 5 分待ちます。

gcloud config set project $SECUNDUS_PROJECT_ID

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

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

2 番目のワークロードを実行する

2 回目のワークロード実行では、Primus Bank と Secundus Bank の共通の顧客を見つけます。次の例に示すように、2 番目のワークロードは「list-common-customers」コマンドを実行し、結果は $SECUNDUS_RESULT_STORAGE_BUCKET/list-common-count に保存されます。

gcloud compute instances create ${WORKLOAD_VM2} \
 --project=${SECUNDUS_PROJECT_ID} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE} \
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
  --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"list-common-customers\",\"gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result\"]""

結果を表示

Secundus プロジェクトで、2 番目のワークロードの結果を表示します。ワークロードが実行を完了し、結果が Cloud Storage バケットで使用可能になるまで 3 ～ 5 分待ちます。

gcloud config set project $SECUNDUS_PROJECT_ID

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

結果は次のリストになります。これは、Primus Bank と Secundus Bank の共通の顧客であるためです。

出力:

Eric
Clinton
Ashley
Cooper

不正なワークロードを実行する

Secundus Bank が Primus Bank のデータにアクセスすることを許可する契約が期限切れになった。そこで、Primus Bank は属性条件を更新して、新しいパートナーである Tertius Bank のサービスアカウントを持つ VM を許可します。

Primus Bank が Workload Identity プールプロバイダを変更する

$PRIMUS_PROJECT_ID で、構成証明検証ツール ID プロバイダの属性条件を更新して、新しいロケーションでワークロードを承認します。

プロジェクトを $PRIMUS_PROJECT_ID に設定します。

gcloud config set project $PRIMUS_PROJECT_ID

次のコマンドを使用して、Tertius Bank の GCP プロジェクト ID をエクスポートします。後で、Primus Bank はこれを使用して、Workload Identity プールプロバイダの属性条件を更新します。Primus Bank は、Secundus Bank ワークロードサービスアカウントの承認を停止しません。これで、Tertius Bank ワークロードサービスアカウントが許可されます。

export TERTIUS_PROJECT_ID=<GCP project-id of Tertius Bank>

Workload Identity プールの OIDC プロバイダを更新します。ここで、'$WORKLOAD_SERVICE_ACCOUNT@$SECUNDUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts が '$WORKLOAD_SERVICE_ACCOUNT@$TERTIUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts. に変更されます。Secundus Bank のワークロードサービスアカウントではなく、Tertius Bank のワークロードサービスアカウントが承認されるようになります。

gcloud iam workload-identity-pools providers update-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 &&
   assertion.submods.container.image_reference == '${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/$PRIMUS_PROJECT_ID/$PRIMUS_ARTIFACT_REPOSITORY/$WORKLOAD_IMAGE_NAME:$WORKLOAD_IMAGE_TAG' && 
'$WORKLOAD_SERVICE_ACCOUNT@$TERTIUS_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts"

ワークロードを再実行する

Secundus Bank が元のワークロードを実行しようとすると、失敗します。エラーを表示するには、元の結果ファイルと VM インスタンスを削除してから、ワークロードの実行を再度試してください。

既存の結果ファイルと VM インスタンスを削除する

プロジェクトを $SECUNDUS_PROJECT_ID プロジェクトに設定します。

gcloud config set project $SECUNDUS_PROJECT_ID

結果ファイルを削除します。

gsutil rm gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

Confidential VM インスタンスを削除します。

gcloud compute instances delete ${WORKLOAD_VM2} --zone=${SECUNDUS_PROJECT_ZONE}

承認されていないワークロードを実行します。

gcloud compute instances create ${WORKLOAD_VM2} \
 --confidential-compute-type=SEV \
 --shielded-secure-boot \
 --maintenance-policy=MIGRATE \
 --scopes=cloud-platform \
 --zone=${SECUNDUS_PROJECT_ZONE}\
 --image-project=confidential-space-images \
 --image-family=confidential-space \
--service-account=${WORKLOAD_SERVICE_ACCOUNT}@${SECUNDUS_PROJECT_ID}.iam.gserviceaccount.com \
 --metadata "^~^tee-image-reference=${PRIMUS_PROJECT_REPOSITORY_REGION}-docker.pkg.dev/${PRIMUS_PROJECT_ID}/${PRIMUS_ARTIFACT_REPOSITORY}/${WORKLOAD_IMAGE_NAME}:${WORKLOAD_IMAGE_TAG}~tee-restart-policy=Never~tee-cmd="[\"list-common-customers\",\"gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result\"]""

エラーを表示

ワークロードの結果ではなく、エラー（The given credential is rejected by the attribute condition）が表示されます。

gsutil cat gs://$SECUNDUS_RESULT_STORAGE_BUCKET/list-common-result

同様に、Primus Bank がワークロードを密かに変更して、Secundus Bank の顧客リスト全体を Primus Bank が所有するバケットに送信しようとした場合、悪意のあるワークロードのダイジェストが Secundus Bank の Workload Identity プールで承認されたイメージダイジェストと異なるため、その試みは失敗します。

5. クリーンアップ

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

Primus Bank の入力 Cloud Storage バケット（$PRIMUS_INPUT_STORAGE_BUCKET)）。
Primus Bank のサービスアカウント（$PRIMUS_SERVICE_ACCOUNT）。
イメージ署名（$PRIMUS_COSIGN_REPOSITORY）を保持する Primus Bank のアーティファクトレジストリ。
Primus Bank の Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）。
Secundus Bank のワークロードサービスアカウント（$WORKLOAD_SERVICE_ACCOUNT）。
Secundus Bank の入力クラウドストレージバケット（$SECUNDUS_INPUT_STORAGE_BUCKET)）。
Secundus Bank のサービスアカウント（$SECUNDUS_SERVICE_ACCOUNT）。
イメージ署名（$SECUNDUS_COSIGN_REPOSITORY）を保持する Secundus Bank のアーティファクトレジストリ。
Secundus Bank の Workload Identity プール（$SECUNDUS_WORKLOAD_IDENTITY_POOL）。
Secundus Bank のワークロードサービスアカウント（$WORKLOAD_SERVICE_ACCOUNT）。
ワークロードコンピューティングインスタンス。
Secundus Bank の結果ストレージバケット（$SECUNDUS_RESULT_STORAGE_BUCKET）。
Primus Bank のアーティファクトリポジトリ（$PRIMUS_ARTIFACT_REPOSITORY）。

./cleanup.sh

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

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

おめでとうございます！

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

Confidential Space を使用して、共有データの機密性を保持しながらセキュリティを確保する方法を学びました。

次のステップ

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

使用中の共有データを Confidential Space で保護する

1. 概要

必要なもの

学習内容

2. クラウド リソースを設定する

始める前に

Primus Bank のクラウド リソースを設定する

Secundus Bank のクラウド リソースを設定する

3. ワークロードを作成する

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

ワークロードを作成する

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

ワークロードを承認する

ワークロードを実行する

最初のワークロードを実行する

結果を表示

2 番目のワークロードを実行する

結果を表示

不正なワークロードを実行する

Primus Bank が Workload Identity プール プロバイダを変更する

ワークロードを再実行する

既存の結果ファイルと VM インスタンスを削除する

承認されていないワークロードを実行します。

エラーを表示

5. クリーンアップ

おめでとうございます！

次のステップ

参考資料

2. クラウドリソースを設定する

Primus Bank のクラウドリソースを設定する

Secundus Bank のクラウドリソースを設定する

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

Primus Bank が Workload Identity プールプロバイダを変更する