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

データ コラボレーター

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

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

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

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

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

をご覧ください。

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

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

• BigQuery

• Cloud SQL

• Cloud Storage

• Filestore

• Persistent Disk

組み込み機能を使用する場合でも、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 属性（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="ISSUER_URI" \
       --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"
   

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

   • 使用している構成証明サービスと一致する issuer-uri:

     • Google Cloud Attestation: https://confidentialcomputing.googleapis.com

     • Intel Trust Authority: https://portal.trustauthority.intel.com

   • 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	文字列の配列	サポート属性を使用して、Confidential VM インスタンスで実行されている本番環境の Confidential Space イメージのセキュリティ バージョンを確認します。Confidential Space のデバッグ イメージにはサポート属性が設定されていません。 有効なサポート属性は次のとおりです。 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 ダイジェストを使用）） 例 ['ECDSA_P256_SHA256:PUBLIC_KEY_FINGERPRINT'].exists(fingerprint, fingerprint in assertion.submods.container.image_signatures.map(sig, sig.signature_algorithm+':'+sig.key_id))
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-monitoring-memory-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_feature 連携するサービス: ワークロード オペレーター: tee-install-gpu-driver メタデータ変数。	列挙	NVIDIA GPU でサポートされている Confidential Computing 機能を検証します。Confidential Space では単一 GPU パススルー（SPT）モードのみがサポートされているため、値は常に SPT になります。 NVIDIA Confidential Computing のサポートの詳細については、 NVIDIA Trusted Computing Solutions（PDF）をご覧ください。 例 assertion.submods.nvidia_gpu.cc_feature == "SPT"
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 モードのワークフローと一致する部分的な機密コンピューティング モードですが、セキュリティ保護が無効になっています。 例 assertion.submods.nvidia_gpu.cc_mode == "ON"
assertion.submods.nvidia_gpu.gpus 連携するサービス: ワークロード オペレーター: tee-install-gpu-driver メタデータ変数。	オブジェクトの配列	証明された各 NVIDIA GPU のクレームを検証します。Confidential Space は、単一の GPU クレームのみをサポートします。 gpus オブジェクトは次のようになります。 { "hwmodel": "GCP_NVIDIA_H100", "ueid": "490457405999046854973671575630853621547794591064", "l4_serial_number": "1216669666319372030078", "driver_version": "570.00", "vbios_version": "96.00.9F.00.01" } 例 次のコードは、最初の GPU ハードウェア モデルが Google Cloudで実行されている NVIDIA H100 であることを確認します。 assertion.submods.nvidia_gpu.gpus[0].hwmodel == "GCP_NVIDIA_H100" 次のコードは、構成証明クレームに GPU 関連のクレームがあることを確認します。 has(assertion.submods.nvidia_gpu.gpus)