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 Bank の顧客データ ファイルを格納するバケット。 |
| クレームを検証する Primus Bank の Workload Identity プール（WIP）。 |
| Primus Bank の Workload Identity プール プロバイダ。構成には、構成証明検証サービスによって署名されたトークンに使用する認可条件が含まれています。 |
|
|
| Primus Bank の |
| Primus Bank の暗号鍵 |
| ワークロード Docker イメージが push されるアーティファクト リポジトリ。 |
- 次の変数は、Secundus プロジェクトの既存のクラウド リソース名で設定できます。変数が設定されている場合、Secundus プロジェクトの対応する既存のクラウド リソースが使用されます。変数が設定されていない場合、クラウド リソース名は project-name から生成され、新しいクラウド リソースが次の一部として作成されます。
| Secundus 銀行の顧客データ ファイルを保存するバケット |
| クレームを検証する Secundus Bank の Workload Identity プール（WIP）。 |
| Secundus Bank の Workload Identity プール プロバイダ。構成証明検証サービスによって署名されたトークンに使用する承認条件が含まれています。 |
|
|
| Secundus Bank の |
| Secundus Bank の暗号鍵 |
| ワークロードの結果を保存するバケット。 |
| ワークロード コンテナ イメージ名。 |
| ワークロード コンテナ イメージのタグ。 |
| ワークロードを実行する 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_BUCKETCloud Storage バケットからデータを読み取ります。objectViewer:$SECUNDUS_INPUT_STORAGE_BUCKETCloud Storage バケットからデータを読み取ります。objectAdmin: ワークロードの結果を$SECUNDUS_RESULT_STORAGE_BUCKETCloud 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 をご覧ください。
- 署名付きコンテナ イメージの Codelab
- マルチパーティ コンピューティングと Confidential Space によってデジタル アセットをトランザクションする方法
- Confidential Space を使用して機密データを分析する