機密リソースを作成してアクセス権を付与する

データ コラボレーター

---

データ コラボレーターは、ワークロードが機密データにアクセスできるように、次のリソースを設定する必要があります。

• 暗号化されたデータ。 Google Cloudに保存されます。

• ワークロードを承認するワークロード ID プール（WIP）。WIP によってワークロードが承認されると、データ コラボレーターの機密データにアクセスして操作できるようになります。

また、データ コラボレーターは、Confidential Space ワークロードの結果をどこに保存するか、その結果が各コラボレーターに固有のものか、共有されるものかを選択する必要があります。たとえば、各データ コラボレーターに属する複数の Cloud Storage バケットに同じ結果を出力するように選択できます。

注: データ コラボレーター リソースが Google CloudIAM によって管理されていない場合、カスタム オーディエンスとオプションのノンスを使用して構成証明トークンをリクエストすることで、これらのリソースへのアクセスを管理できます。ワークロードの作成者と協力して、これを実装します。詳細については、 Google Cloud IAM で管理されていないリソースにアクセスする

をご覧ください。

暗号化されたデータを保存する

データを保存する Google Cloud サービスを使用して、機密データをホストできます。たとえば、次のいずれかのサービスを使用できます。

• BigQuery

• Cloud SQL

• Filestore

• Persistent Disk

• Cloud Storage

組み込み機能を使用する場合でも、Cloud Key Management Service（Cloud KMS）などの機能を使用する場合でも、このデータが保存時に暗号化されていることを確認する必要があります。

注意: データでワークロードをテストする場合は、個人情報を使用しないでください。同じ形式のフェイクデータを設定し、ワークロードをロックダウンする準備ができるまでテストします。

WIP でワークロードを承認する

WIP は、Confidential Space が外部ワークロードに フェデレーション ID として機密データへのアクセスと操作を許可するために使用するメカニズムです。フェデレーション ID は、独自のプロジェクト内のプリンシパルとして扱われる外部エンティティです。これにより、IAM ロールを付与して特定のリソースへのアクセス権を付与したり、サービス アカウントを権限借用して同じことを行ったりできます。

データ コラボレーターは、連携 ID として認証するエンティティのルールを設定する WIP 内にプロバイダを設定します。Confidential Space の場合、プロバイダで次の項目を定義する必要があります。

• 証明書サービス: このサービスは、ワークロードが Confidential VM インスタンスであることを検証し、最終的に OpenID Connect（OIDC）証明書トークンを WIP プロバイダに返します。ワークロード オペレーターは、使用する構成証明サービスを設定します。アクセス権を付与するには、WIP プロバイダに追加された構成証明サービスと一致する必要があります。

• 属性マッピング: 認証エンティティ（この場合はワークロードを実行している VM インスタンス）によって作成されたアサーションにマッピングされる Security Token Service アクセス トークンの属性。アサーションは、VM インスタンス自体、Confidential Space イメージ、ワークロード コンテナによって行われ、ワークロードによって WIP プロバイダに渡されます。これらの属性は、Cloud Logging の監査証跡や、ワークロード イメージ コンテナ ダイジェストなどのエンティティ アサーションの認証に基づいて IAM を介してロールを付与する場合などに使用されます。詳しくは、属性マッピングをご覧ください。

• 構成証明ポリシー: 認証エンティティがアクセス権を取得するために、そのアサーションに基づいて満たす必要のある一連の条件。

ワークロードが起動すると、Confidential Space Launcher は、ワークロード オペレーターによって定義された証明書サービスに証明書レポートを送信します。証明書サービスは Confidential VM インスタンスを検証し、OIDC 証明書トークンを返します。このトークンの有効期間は 1 時間で、自動的に更新されます。

次に、ワークロードによって証明書トークンが WIP プロバイダに渡され、プロバイダはそれを使用して、アサーションがプロバイダで定義された証明書ポリシーに合格したことを確認します。満たしている場合、ワークロードは機密リソースにアクセスできます。

注: トークンの検証に Google のサーバーを使用する代わりに、長期証明書を使用して自分で構成証明トークンを検証できます。

外部ワークロード アクセス

WIP とプロバイダを設定する前に、ワークロードがリソースにアクセスする方法（リソースへの直接アクセスまたはサービス アカウントの権限借用）を選択する必要があります。

リソースへの直接アクセス

ワークロードには、直接リソース アクセス方式をおすすめします。

この方法では、認証エンティティのアサーションに関連付けられた WIP プロバイダにフェデレーション ID を設定します。これにより、ワークロードのコンテナ イメージ ダイジェストなどの属性に基づいて、ワークロードが IAM バインディングを介してリソースに直接アクセスできるように承認されます。

リソースへの直接アクセスには次のようなメリットがあります。

• データ コラボレーターがワークロード サービス アカウントの権限を借用するサービス アカウントを設定する必要がないため、Confidential Space 環境の設定は手順が少なくなります。

• ワークロードは、IAM によって決定された特定のリソースにのみアクセスできます。これは、権限が過剰なサービス アカウントや権限借用権限によって、攻撃者に意図しないアクセス権が付与される可能性があるサービス アカウントの権限借用方法よりも安全です。

• 各リソース アクセスは、複数のワークロードで共有される可能性のある、権限を借用したサービス アカウントの ID ではなく、ワークロード VM インスタンスのフェデレーション ID でロギングされます。ワークロード VM インスタンスの ID には、コンテナのイメージ ダイジェスト、ワークロードが動作しているプロジェクト番号、ワークロードを実行している VM インスタンスの ID などの詳細を含めることができます。これにより、より詳細な監査証跡が提供されます。

• VM インスタンスの selfLink プロパティを WIP プロバイダの google.subject 属性にマッピングする必要はありません。selfLink 値が長すぎると、この属性の 127 バイトの制限を超える可能性があり、WIP プロバイダの認証が失敗します。

サービス アカウントの権限借用

サービス アカウントの権限借用方法では、各データ コラボレーターがプライベート データを復号するためのサービス アカウントを設定し、そのサービス アカウントを独自の WIP に関連付けます。また、WIP プロバイダでワークロード サービス アカウントを指定します。これにより、ワークロード サービス アカウントはデータ コラボレーター サービス アカウントの権限を借用して、機密データを取得して操作できます。

サービス アカウントの権限借用は、次のシナリオでのみ使用する必要があります。

• イメージ署名を認証情報として使用する必要がある場合。署名で使用される構文は、属性マッピングでは機能しません。

• 連携 ID をサポートしていない API にアクセスする場合。

VM インスタンスの selfLink プロパティが非常に長い場合、サービス アカウントの権限借用メソッドで WIP プロバイダに対する認証が失敗することがあります。これは、構成証明トークンの sub クレーム（selfLink 値に設定）が WIP プロバイダで google.subject 属性にマッピングされるためです。google.subject 属性には 127 バイトの上限があります。

VM インスタンスの selfLink 値が 127 バイトを超える場合は、VM インスタンスの名前を変更して selfLink を短くするか、代わりに直接リソース アクセス方法を使用する必要があります。

WIP とプロバイダを設定する

プロバイダを設定する手順は、直接リソース アクセスを使用するか、サービス アカウントの権限借用を使用するかによって異なります。

リソースへの直接アクセス

直接リソース アクセス方法では、WIP とプロバイダを設定してから、特定のワークロード コンテナ イメージ ダイジェストに基づいて IAM ロールを設定します。

WIP とプロバイダを設定する

WIP とプロバイダを設定する手順は次のとおりです。

1. WIP を作成します。

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. WIP で OIDC プロバイダを作成します。

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="https://confidentialcomputing.googleapis.com/" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=\"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest" \
       --attribute-condition="assertion.swname == 'CONFIDENTIAL_SPACE' \
           && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   この例では次の値を使用します。

   • https://confidentialcomputing.googleapis.com/ の issuer-uri。これは、Google Cloud Attestation が証明書サービスとして使用されていることを意味します。

   • https://sts.googleapis.com の allowed-audiences。これは、認証情報をアクセス トークンと交換する Google の Security Token Service です。

   • google.subject の attribute-mapping。値は次のとおりです。

     \"gcpcs::\"+assertion.submods.container.image_digest+\"::\"+assertion.submods.gce.project_number+\"::\"+assertion.submods.gce.instance_id,attribute.image_digest=assertion.submods.container.image_digest
     

     この値は、Common Expression Language（CEL）を使用して構築されます。次の値が gcpcs 属性に割り当てられ、ワークロードがリソースにアクセスするたびに Cloud Logging に表示されます。

     • assertion.submods.container.image_digest: ワークロード コンテナ イメージのダイジェスト。

     • assertion.submods.gce.project_number: VM インスタンスのプロジェクト番号。

     • assertion.submods.gce.instance_id: VM インスタンスの ID。

     また、attribute.image_digest はワークロード コンテナ イメージ ダイジェストである assertion.submods.container.image_digest に設定されます。この属性はマッピングされているため、特定イメージ ダイジェストに基づいて連携 ID に IAM ロールを付与できます。

     google.subject 値の合計長が 127 バイト未満である限り、使用可能なワークロードのアサーションをマッピングできます。

   • 次の attribute-conditions。これらは構成証明ポリシーを形成します。これらの条件がワークロードのアサーションと一致する場合、ワークロードは連携 ID として機密リソースにアクセスできます。

     • assertion.swname == 'CONFIDENTIAL_SPACE': Confidential Space が VM で実行されているソフトウェアであり、すべての組み込みのセキュリティ保証があることを確認します。

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: 本番環境の Confidential Space イメージが使用されており、STABLE サポート属性があることを確認します。

     使用できる属性条件の詳細については、証明書ポリシーを作成するをご覧ください。

フェデレーション ID に IAM ロールを付与する

WIP プロバイダを作成したら、ID のワークロード イメージ コンテナ ダイジェストが想定値と一致するかどうかに基づいて、連携 ID に IAM ロールを付与できます。

次の例では、特定の Cloud Key Management Service 鍵を復号する権限をフェデレーション ID に付与する方法を示します。

gcloud kms keys add-iam-policy-binding \
    projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
    --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/attribute.image_digest/WORKLOAD_CONTAINER_IMAGE_DIGEST" \
    --role=roles/cloudkms.cryptoKeyDecrypter

サービス アカウントの権限借用

サービス アカウントの権限借用方法には、次の処理が含まれます。

1. データ コラボレーター プロジェクトごとにサービス アカウントを作成し、機密データを復号する権限を付与します。

2. 各データ コラボレーター プロジェクトに WIP を作成し、作成したばかりの各プロジェクトのサービス アカウントを WIP に関連付けます。

3. 各 WIP に WIP プロバイダを作成し、データ コラボレーター サービス アカウントの権限借用を許可するアカウントとしてワークロード サービス アカウントを指定します。

機密データを復号するサービス アカウントを設定する

1. データ コラボレーター プロジェクトにサービス アカウントを作成します。

   gcloud iam service-accounts create DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME
   

   機密データの復号に必要な権限をサービス アカウントに付与します。たとえば、Cloud Storage の機密ファイルを Cloud KMS で暗号化する場合は、そのデータを復号する権限をサービス アカウントに付与する必要があります。

   gcloud kms keys add-iam-policy-binding \
       projects/DATA_COLLABORATOR_PROJECT_ID/locations/global/keyRings/DATA_COLLABORATOR_KEYRING_NAME/cryptoKeys/DATA_COLLABORATOR_KEY_NAME \
       --member=serviceAccount:DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/cloudkms.cryptoKeyDecrypter
   

WIP とプロバイダを設定する

WIP とプロバイダを設定するには、各データ コラボレーター プロジェクトで次の手順を完了します。

1. WIP を作成します。

   gcloud iam workload-identity-pools create DATA_COLLABORATOR_POOL_NAME \
       --location=global
   

2. 偽装するサービス アカウントを WIP に roles/iam.workloadIdentityUser ロールで関連付けます。

   gcloud iam service-accounts add-iam-policy-binding \
       DATA_COLLABORATOR_SERVICE_ACCOUNT_NAME@DATA_COLLABORATOR_PROJECT_ID.iam.gserviceaccount.com \
       --member="principalSet://iam.googleapis.com/projects/DATA_COLLABORATOR_PROJECT_NUMBER/locations/global/workloadIdentityPools/DATA_COLLABORATOR_POOL_NAME/*" \
       --role=roles/iam.workloadIdentityUser
   

3. WIP に OIDC プロバイダを作成し、データ コラボレーターのサービス アカウントの権限を借用できるように、その中にワークロード サービス アカウントを定義します。

   gcloud iam workload-identity-pools providers create-oidc attestation-verifier \
       --location=global \
       --workload-identity-pool=DATA_COLLABORATOR_POOL_NAME \
       --issuer-uri="https://confidentialcomputing.googleapis.com/" \
       --allowed-audiences="https://sts.googleapis.com" \
       --attribute-mapping="google.subject=assertion.sub" \
       --attribute-condition="assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST' \
   && 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_OPERATOR_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts \
   && assertion.swname == 'CONFIDENTIAL_SPACE' \
   && 'STABLE' in assertion.submods.confidential_space.support_attributes"
   

   この例では次の値を使用します。

   • https://confidentialcomputing.googleapis.com/ の issuer-uri。これは、Google Cloud Attestation が証明書サービスとして使用されていることを意味します。

   • https://sts.googleapis.com の allowed-audiences。これは、認証情報をアクセス トークンと交換する Google の Security Token Service です。

   • google.subject の attribute-mapping。値は assertion.sub です。これは、構成証明トークンの sub クレームで定義されている VM インスタンスの selfLink です。

     ワークロードがリソースにアクセスするたびに、VM インスタンス selfLink が Cloud Logging に表示されます。

   • 次の attribute-conditions。これらは構成証明ポリシーを形成します。これらの条件がワークロードのアサーションと一致する場合、ワークロードは連携 ID としてリソースにアクセスできます。

     • assertion.submods.container.image_digest == 'WORKLOAD_CONTAINER_IMAGE_DIGEST': ワークロード コンテナ イメージのダイジェストが想定値と一致することを確認します。

     • 'WORKLOAD_SERVICE_ACCOUNT_NAME@WORKLOAD_PROJECT_ID.iam.gserviceaccount.com' in assertion.google_service_accounts: ワークロードに接続されたサービス アカウントが想定されるサービス アカウントと一致することを確認し、それを使用してデータ コラボレーター サービス アカウントの権限を借用します。

     • assertion.swname == 'CONFIDENTIAL_SPACE': Confidential Space が VM で実行されているソフトウェアであり、すべての組み込みのセキュリティ保証があることを確認します。

     • 'STABLE' in assertion.submods.confidential_space.support_attributes: 本番環境の Confidential Space イメージが使用されており、STABLE サポート属性があることを確認します。

     使用できる属性条件の詳細については、証明書ポリシーを作成するをご覧ください。

証明書ポリシーを作成する

WIP の作成の一環として、証明書ポリシーを作成する必要があります。認証エンティティのアサーションは、データにアクセスできるようにポリシーと一致する必要があります。

ポリシーは Common Expression Language（CEL）で記述され、&& 演算子で連結できる一連のステートメントで構成されます。

ステートメントでは、Confidential Space イメージ、ワークロード コンテナ イメージ、または VM インスタンスのアサーションを変数として使用し、指定した値を式として使用します。たとえば、ワークロードが Confidential Space を使用していること、STABLE Confidential Space イメージを使用する必要があること、ワークロード VM インスタンスが実行されているゾーンが us-central1-a であることを強制するポリシーを次に示します。

assertion.swname == 'CONFIDENTIAL_SPACE' \
&& 'STABLE' in assertion.submods.confidential_space.support_attributes" \
&& assertion.submods.gce.zone == "us-central1-a"

詳しくは、証明書のアサーションをご覧ください。

証明書のアサーション

次の表に、証明書ポリシーの作成に使用できるアサーションの詳細を示します。ポリシーは、Confidential Space イメージ、ワークロード コンテナ、VM インスタンスによって行われたアサーションを検証できます。

画像アサーション

アサーション	タイプ	説明
assertion.dbgstat 連携するサービス: ワークロード オペレーター: --image-family 値。	定義された文字列	Confidential Space イメージがデバッグ バージョンか本番環境バージョンかを確認します。 有効な値は次のとおりです。 enable: デバッグ イメージが使用されていることを確認します。 disabled-since-boot: 本番環境イメージが使用されていることを確認します。 例 次のコードは、Confidential Space イメージのデバッグ バージョンが使用されていることを確認します。 assertion.dbgstat == "enable" 次のコードは、Confidential Space イメージの本番環境バージョンが使用されていることを確認します。 assertion.dbgstat == "disabled-since-boot"
assertion.submods.confidential_space.support_attributes	文字列配列	TEE のセキュリティ バージョンが本番環境の Confidential Space イメージであることを確認します。Confidential Space のデバッグ イメージにはサポート属性が設定されていません。 サポート属性は次の 3 つです。 LATEST: これは最新バージョンのイメージであり、サポートされています。LATEST イメージも STABLE と USABLE です。 STABLE: このバージョンのイメージはサポートされ、脆弱性のモニタリングが行われます。STABLE イメージも USABLE です。 USABLE: この属性のみを持つイメージはサポートされず、脆弱性のモニタリングは行われません。ご自身の責任で操作するようお願いいたします。 EXPERIMENTAL: この属性のみを持つ画像は、プレビュー機能を利用します。これはテスト専用です。本番環境では使用しないでください。EXPERIMENTAL 画像に LATEST、STABLE、USABLE の属性が設定されることはありません。 注意: Confidential Space のデフォルト トークンは 1 時間ごとに更新されるため、長時間実行されるワークロードには LATEST の指定はおすすめしません。ワークロードの実行中に Confidential Space イメージが更新されることがあります。つまり、ワークロードが最新バージョンではなくなり、その結果、証明書が失敗します。 例 次のコードは、Confidential Space イメージの安定版が使用されていることを確認します。 "STABLE" in assertion.submods.confidential_space.support_attributes
assertion.swname	定義された文字列	証明を行うエンティティで実行されているソフトウェアを検証します。値は常に CONFIDENTIAL_SPACE です。 例 assertion.swname == "CONFIDENTIAL_SPACE"
assertion.swversion	文字列配列	Confidential Space イメージのソフトウェア バージョンを検証します。代わりに assertion.submods.confidential_space.support_attributes を使用して、イメージの最新バージョンをターゲットにすることをおすすめします。 例 int(assertion.swversion[0]) == 230103

コンテナ アサーション

アサーション	タイプ	説明
assertion.submods.container.cmd_override 連携するサービス: ワークロード作成者: allow_cmd_override 起動ポリシー。 ワークロード オペレーター: tee-cmd メタデータ変数。	文字列配列	ワークロード イメージで使用されている CMD コマンドとパラメータを確認します。 例 次のコードは、ワークロード イメージの CMD が上書きされていないことを確認します。 size(assertion.submods.container.cmd_override) == 0 次のコードは、CMD オーバーライドの唯一のコンテンツが program であることを確認します。 assertion.submods.container.cmd_override == ['program']
assertion.submods.container.env 連携するサービス: ワークロード作成者: allow_env_override 起動ポリシー。 ワークロード オペレーター: tee-env-ENVIRONMENT_VARIABLE_NAME メタデータ変数。	JSON オブジェクト	環境変数とそれらの値がコンテナに明示的に渡されていることを確認します。 例 次のコードは、環境変数 example-env-1 が value-1 に設定され、example-env-2 が value-2 に設定されていることを確認します。 assertion.submods.container.env == {"example-env-1": "value-1", "example-env-2": "value-2"}
assertion.submods.container.env_override 連携するサービス: ワークロード作成者: allow_env_override 起動ポリシー。 ワークロード オペレーター: tee-env-ENVIRONMENT_VARIABLE_NAME メタデータ変数。	文字列	ワークロード オペレーターがコンテナ内の環境変数を上書きしたかどうかを確認します。 例 次のコードは、ワークロード オペレータが example 環境変数をオーバーライドしていないことを確認します。 !has(assertion.submods.container.env_override.example) 次のコードは、ワークロード オペレーターが環境変数を上書きしていないことを確認します。 size(assertion.submods.container.env_override) == 0
assertion.submods.container.image_digest	文字列	ワークロード コンテナのイメージ ダイジェストを検証します。この条件を指定すると、複数の関係者が、データへのアクセスを許可する承認済みワークロードについて合意できます。 例 assertion.submods.container.image_digest == "sha256:837ccb607e312b170fac7383d7ccfd61fa5072793f19a25e75fbacb56539b86b"
assertion.submods.container.image_id	文字列	ワークロード コンテナのイメージ ID を検証します。 例 assertion.submods.container.image_id == "sha256:652a44b0e911271ba07cf2915cd700fdfa50abd62a98f87a57fdebc59843d93f"
assertion.submods.container.image_reference 連携するサービス: ワークロード オペレーター: tee-image-reference メタデータ変数。	文字列	Confidential Space イメージ上で実行されているワークロード コンテナの場所を検証します。 例 assertion.submods.container.image_reference == "us-docker.pkg.dev/PROJECT_ID/WORKLOAD_CONTAINER:latest"
assertion.submods.container.image_signatures 連携するサービス: ワークロード オペレーター: tee-signed-image-repos メタデータ変数。	JSON オブジェクト	イメージに特定の署名があるか、公開鍵と署名アルゴリズムで署名されていることを検証します。この条件を指定すると、複数の関係者が、データへのアクセスを許可する承認済みワークロードについて合意できます。 アサーションには次の要素を含めることができます。 key_id: 公開鍵の 16 進数フィンガープリント。フィンガープリントを取得するには、次のコマンドを実行します。 openssl pkey -pubin -in public_key.pem -outform DER | openssl sha256 ここで、public_key.pem は PEM 形式の公開鍵です。 signature: 署名付きコンテナに関連付けられ、 Simple Signing 形式に準拠するペイロードの署名。 signature_algorithm: 鍵の署名に使用されるアルゴリズム。次のいずれかになります。 RSASSA_PSS_SHA256（SHA-256 ダイジェストを使用する RSASSA-PSS） RSASSA_PKCS1V15_SHA256（SHA-256 ダイジェストを使用する RSASSA-PKCS1 v1_5） ECDSA_P256_SHA256（P-256 曲線上の ECDSA（SHA-256 ダイジェストを使用）） 例 assertion.swname == 'CONFIDENTIAL_SPACE' && ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id)) && 'serviceaccount.iam.gserviceaccount.com' in assertion.google_service_accounts"
assertion.submods.container.restart_policy 連携するサービス: ワークロード オペレーター: tee-restart-policy メタデータ変数。	定義された文字列	ワークロードが停止したときのコンテナ ランチャーの再起動ポリシーを検証します。 有効な値は次のとおりです。 Never（デフォルト） Always OnFailure 例 assertion.submods.container.restart_policy == "Never"

VM アサーション

アサーション	タイプ	説明
assertion.google_service_accounts 連携するサービス: ワークロード オペレータ: tee-impersonate-service-accounts メタデータ変数と --service-account 値。	文字列配列	指定したサービス アカウントが、ワークロードを実行している VM に接続されているか、VM メタデータで tee-impersonate-service-accounts を使用して一覧表示されていることを確認します。 例 [e-mail] in assertion.google_service_accounts
assertion.hwmodel	文字列	基盤となる Confidential Computing テクノロジーを検証します。サポートされているプラットフォームは次のとおりです。 GCP_AMD_SEV INTEL_TDX 例 assertion.hwmodel == "GCP_AMD_SEV"
assertion.submods.confidential_space.monitoring_enabled 連携するサービス: ワークロード作成者: monitoring_memory_allow 起動ポリシー。 ワークロード オペレーター: tee-memory-monitoring-enable メタデータ変数。	ブール値	証明を行うエンティティのモニタリング状態を確認します。 例 assertion.submods.confidential_space.monitoring_enabled.memory == true
assertion.submods.gce.instance_id	文字列	VM インスタンス ID を検証します。 例 assertion.submods.gce.instance_id == "0000000000000000000"
assertion.submods.gce.instance_name	文字列	VM インスタンスの名前を確認します。 例 assertion.submods.gce.instance_name == "workload-vm"
assertion.submods.gce.project_id	文字列	指定したプロジェクト ID で VM が Google Cloud プロジェクトを実行していることを確認します。 例 assertion.submods.gce.project_id == "project-id"
assertion.submods.gce.project_number	文字列	指定したプロジェクト番号で VM が Google Cloud プロジェクトで実行されていることを確認します。 例 assertion.submods.gce.project_number == "00000000000"
assertion.submods.gce.zone 連携するサービス: ワークロード オペレーター: --zone 値。	文字列	VM が指定されたゾーンで実行されていることを確認します。 例 assertion.submods.gce.zone == "us-central1-a"
assertion.submods.nvidia_gpu.cc_mode 連携するサービス: ワークロード オペレーター: tee-install-gpu-driver メタデータ変数	定義された文字列	NVIDIA の Confidential Computing ドライバのステータスを確認します。有効な値は次のとおりです。 OFF: NVIDIA Confidential Computing 機能はアクティブになっていません。 ON: NVIDIA H100 のハードウェア、ファームウェア、ソフトウェアで Confidential Computing 機能が完全に有効になっています。 DEVTOOLS: GPU は、ON モードのワークフローに一致する部分的な Confidential Computing モードですが、セキュリティ保護が無効になっています。 例 assertion.submods.nvidia_gpu.cc_mode == "ON"