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

データ コラボレーター

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

• 暗号化されたデータ。 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 ロールを付与して特定のリソースへのアクセス権を付与したり、サービス アカウントの権限を借用して同じことを行うことができます。

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

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

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

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

ワークロードが開始されると、Confidential Space ランチャーは、ワークロード オペレーターによって定義された構成証明サービスに構成証明レポートを送信します。このサービスは、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 プロバイダの認証に失敗することがあります。これは、selfLink 値に設定されている証明書トークンの sub クレームが、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. roles/iam.workloadIdentityUser ロールを使用して、権限を借用するサービス アカウントを WIP に接続します。

   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"
   

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

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

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

   • attribute-mapping が google.subject で、値が 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 のデバッグ イメージにはサポート属性が設定されていません。 次の表に、本番環境の Confidential Space イメージに存在するサポート属性を示します。 サポート属性 説明 LATEST LATEST イメージには、次のサポート属性もあります。 STABLE USABLE イメージの有効期間: 約 1 か月。この後、LATEST サポート属性は削除されます。 これは最新バージョンの Confidential Space イメージであり、脆弱性をサポートし、モニタリングします。 長時間実行されるワークロードの場合、証明書ポリシーの一部として LATEST を指定しないことをおすすめします。これは、ワークロードの実行中に Confidential Space イメージが更新され、使用している Confidential Space イメージが LATEST ではなくなり、Confidential Space のデフォルト トークンが次に更新されたときにワークロードの証明書が失敗する可能性があるためです。 STABLE STABLE イメージには、次のサポート属性もあります。 USABLE イメージの有効期間: 約 6 か月。2027 年 4 月 1 日以降、イメージの有効期間が終了すると、STABLE サポート属性は削除されます。 STABLE 属性を持つイメージは、6 か月間サポートされ、脆弱性のモニタリングが行われます。STABLE 属性に基づいて証明書ポリシーを作成することをおすすめします。 まれに、通常の 6 か月のサポート期間中に STABLE 属性が削除されることがあります。たとえば、重大な脆弱性が発見された場合などです。 USABLE USABLE 属性のみを持つイメージは引き続き使用できますが、非推奨と見なされます。非推奨のイメージはサポートされておらず、6 か月以上前のものです。自己責任で使用してください。 USABLE イメージには deprecated.deprecated プロパティがあります。その値は、イメージが非推奨になると予想されるタイムスタンプです。イメージのプロパティは、 gcloud compute images describe コマンドまたは images.get REST メソッドで表示できます。次に例を示します。 gcloud compute images describe confidential-space-240800 \ --format=json \ --project=confidential-space-images EXPERIMENTAL この属性のみを持つイメージは、プレビュー機能を使用します。EXPERIMENTAL イメージはテスト専用であり、本番環境では使用しないでください。 EXPERIMENTAL イメージに LATEST、STABLE、USABLE 属性が設定されることはありません。 Confidential Space イメージは最新の状態に保つことをおすすめします。Confidential Space イメージを更新する方法については、 Confidential Space イメージを更新するをご覧ください。 重要: Confidential Space イメージは、重大な脆弱性の発見などのイベントにより、取り消されることがあります。イメージが取り消されると、構成証明トークンの swname クレームが GCE に設定されるか、トークンをリクエストしたときにワークロードが RIMS_VALIDATION_FAILED メッセージを受信します。 例 次のコードは、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 モードのワークフローに一致する部分的な Confidential Computing モードですが、セキュリティ保護は無効になっています。 例 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)