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

使用中の共有データを 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 の実行に必要な Cloud リソースを構成する方法
Confidential Space VM イメージを実行している Confidential VM でワークロードを実行する方法
ワークロードコードの属性（what）、Confidential Space 環境（where）、ワークロードを実行しているアカウント（who）に基づいて、保護されたリソースへのアクセスを承認する方法。

この Codelab では、Primus 銀行と Secundus 銀行の間に機密スペースを設定して、アカウントリスト全体を共有することなく、両行の共通顧客を特定します。次の作業を行います。

ステップ 1: Primus 銀行と Secundus 銀行に必要なクラウドリソースを設定する。これらのクラウドリソースには、Primus 銀行と Secundus 銀行の Cloud Storage バケット、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: ワークロードが実行されると、ワークロードと環境のクレームを含む構成証明検証サービストークンを提供して、データコラボレータ（Primus Bank と Secundus Bank）のクラウドリソースへのアクセスをリクエストします。トークンのワークロード測定クレームが Primus 銀行と Secundus 銀行の Workload Identity プールの属性条件と一致する場合、それぞれのクラウドリソースへのアクセス権を持つサービスアカウントアクセストークンが返されます。クラウドリソースにアクセスできるのは、Confidential Space 内で実行されているワークロードのみです。
ステップ 5（a）: 特定の地域の Primus Bank の顧客数をカウントする最初のワークロードを実行します。このワークロードの場合、Primus Bank はデータコラボレータとワークロード作成者であり、Confidential Space で実行されるワークロードに暗号化された顧客リストを提供します。Secundus Bank はワークロードオペレーターであり、Confidential Space でワークロードを実行します。
ステップ 5（b）: Primus 銀行と Secundus 銀行の共通顧客を検索する 2 番目のワークロードを実行します。このワークロードでは、Primus Bank と Secundus Bank の両方がデータコラボレータになります。暗号化された顧客リストを Confidential Space で実行されているワークロードに提供します。Secundus Bank は、ワークロードオペレーターになります。このワークロードは、共通の顧客を見つけるために Secundus Bank の暗号化された顧客リストにもアクセスする必要があるため、Secundus Bank からも承認されます。この場合、Secundus Bank は、Primus Bank のステップ 4 で説明したように、ワークロードを実行しているユーザー、ワークロードの機能、ワークロードの実行場所の属性に基づいて、ワークロードに顧客データへのアクセスを許可します。

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

始める前に

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

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

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

cd confidential-space/codelabs/bank_data_analysis_codelab/scripts

以下に示すように、必要なプロジェクト環境変数が設定されていることを確認します。GCP プロジェクトの作成の詳細については、こちらの Codelab をご覧ください。プロジェクト ID の取得方法と、プロジェクト 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`	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 銀行の顧客データファイルを保存するバケット
`$SECUNDUS_WORKLOAD_IDENTITY_POOL`	クレームを検証する Secundus Bank の Workload Identity プール（WIP）。
`$SECUNDUS_WIP_PROVIDER`	Secundus Bank の Workload Identity プールプロバイダ。構成証明検証サービスによって署名されたトークンに使用する承認条件が含まれています。
`$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 管理者、ストレージ管理者、Artifact Registry 管理者、サービスアカウント管理者、IAM Workload Identity プール管理者が必要です。
$SECUNDUS_PROJECT_ID には、Compute 管理者、ストレージ管理者、サービスアカウント管理者、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）: プロバイダで構成された属性条件に基づいてクレームを検証します。
上記の Workload Identity プール（$PRIMUS_WORKLOAD_IDENTITY_POOL）に接続されているサービスアカウント（$PRIMUS_SERVICE_ACCOUNT）には、KMS 鍵を使用してデータを復号する（roles/cloudkms.cryptoKeyDecrypter ロールを使用）、Cloud Storage バケットからデータを読み取る（objectViewer ロールを使用）、サービスアカウントを Workload Identity プールに接続する（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）: プロバイダで構成された属性条件に基づいてクレームを検証します。
上記の Workload Identity プール（$SECUNDUS_WORKLOAD_IDENTITY_POOL）に接続されているサービスアカウント（$SECUNDUS_SERVICE_ACCOUNT）には、KMS 鍵を使用してデータを復号する（roles/cloudkms.cryptoKeyDecrypter ロールを使用）、Cloud Storage バケットからデータを読み取る（objectViewer ロールを使用）、サービスアカウントを Workload Identity プールに接続する（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 の終了後にログを使用できます。
objectViewer: $PRIMUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取ります。
objectViewer: $SECUNDUS_INPUT_STORAGE_BUCKET Cloud Storage バケットからデータを読み取ります。
objectAdmin: ワークロードの結果を $SECUNDUS_RESULT_STORAGE_BUCKET Cloud Storage バケットに書き込みます。

./create_workload_service_account.sh

ワークロードを作成する

このステップでは、この Codelab で使用するワークロードの Docker イメージを作成します。ワークロードは、次の機能を備えた単純な GoLang アプリケーションです。

指定した地域のユーザー数をカウントします。
それぞれの Cloud Storage バケットに保存されている顧客リストから、Primus 銀行と Secundus 銀行の共通顧客を検索します。

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

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

./create_workload.sh

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

ワークロードを承認する

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

内容: 確認済みのコード
Where: 安全な環境
Who: 信頼できるオペレーター

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

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

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

内容: $PRIMUS_ARTIFACT_REPOSITORY リポジトリにアップロードされた最新の $WORKLOAD_IMAGE_NAME。
使用条件: 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 は、次の情報に基づいてワークロードに顧客データへのアクセスを許可したいと考えています。

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

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

一方、Secundus Bank はイメージを取得するリポジトリを管理していないため、この前提を安全に立てることはできません。代わりに、ワークロードの image_digest に基づいてワークロードへのアクセスを承認します。Primus 銀行が別のイメージを参照するように変更できる image_reference とは異なり、Primus 銀行は、前述のステップで Secundus 銀行が監査したイメージ以外のイメージを image_digest が参照するようにすることはできません。

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 の Workload Identity プールと Secundus の Workload Identity プールからアクセストークンを取得し、それぞれ 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 銀行と Secundus 銀行の共通顧客です。

出力:

Eric
Clinton
Ashley
Cooper

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

Primus 銀行と Secundus 銀行との間で、Secundus 銀行が Primus 銀行のデータにアクセスすることを許可する契約が期限切れになりました。そこで、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 銀行は、Secundus 銀行のワークロードサービスアカウントの承認を停止しません。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 の Cloud Storage バケットを入力します（$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. Cloud リソースを設定する

始める前に

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

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

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

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

ワークロードを作成する

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

ワークロードを承認する

ワークロードを実行する

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

結果を表示

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

結果を表示

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

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

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

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

不正なワークロードを実行します。

エラーを表示

5. クリーンアップ

おめでとうございます！

次のステップ

参考資料

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

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

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

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