マネージド ワークロード ID を使用したバックエンド mTLS の概要

このドキュメントでは、マネージド ワークロード ID を使用して、アプリケーション ロードバランサとそのバックエンド間で相互 TLS（mTLS）を実現する方法の概要について説明します。マネージド ワークロード ID は、Certificate Authority Service から X.509 証明書を自動的にプロビジョニングして管理します。

マネージド ワークロード ID を使用せずにバックエンド mTLS を実現することもできます。マネージド ワークロード ID を使用しないバックエンド mTLS の詳細については、バックエンド認証済み TLS とバックエンド mTLS の概要をご覧ください。

このドキュメントの情報は、次のドキュメントで紹介されているコンセプトに基づいています。

ロードバランサのマネージド ワークロード ID の概要

マネージド ワークロード ID を使用しない場合、バックエンド mTLS を設定するには、複数のリソースを構成する必要があります。マネージド ID をロードバランサのバックエンド サービスに割り当てると、マネージド ワークロード ID は、クライアント証明書、信頼構成、バックエンド認証構成など、mTLS に必要なリソースを自動的に作成します。

バックエンド mTLS の場合、ロードバランサのバックエンド サービス リソースは、バックエンド（宛先ワークロード）に対して自身を認証するソース ワークロードとして機能します。

SPIFFE ID で表されるマネージド ID をロードバランサのバックエンド サービスに割り当てることができます。Google Cloud Certificate Authority Service は、SPIFFE ID の X.509 証明書を自動的にプロビジョニングします。この SPIFFE ID の X.509 証明書は、SPIFFE 検証可能 ID ドキュメント（SVID）とも呼ばれます。ロードバランサのバックエンド サービスとそのバックエンドは、SVID を使用して mTLS 認証で相互に認証します。

次の図は、ロードバランサ（ソース ワークロード）とバックエンド（宛先ワークロード）がマネージド ワークロード ID を使用して相互に認証する様子を示しています。

マネージド ワークロード ID を使用するバックエンド mTLS。
マネージド ワークロード ID を使用したバックエンド mTLS（クリックして拡大）

次の例は、SPIFFE ID のラッパーとして機能する X.509-SVID の例です。URI として表される SPIFFE ID は、X.509 証明書のサブジェクト代替名（SAN）でエンコードされます。

Issuer:
    C=US
    O=Example Inc.
    CN=Example CA

Validity:
    Not Before: Jun 14 00:00:00 2025 GMT
    Not After : Jun 16 00:00:00 2025 GMT

Subject (Distinguished Name):
    C=US
    O=Example Inc.
    OU=Production
    CN=api.example.com

Subject Public Key Info:
    Public Key Algorithm: RSA Encryption
    RSA Public-Key: (2048 bit)

X.509v3 Extensions:
    Subject Alternative Name (SAN):
        DNS: api.example.com
        URI: spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

この出力には次の値が含まれます。

  • WORKLOAD_IDENTITY_POOL_ID: Workload Identity プールの ID
  • PROJECT_NUMBER:Google Cloud プロジェクトのプロジェクト番号
  • NAMESPACE_ID: Namespace ID
  • MANAGED_IDENTITY_ID: マネージド ID の ID

マネージド ワークロード ID を使用するメリット

バックエンド mTLS にマネージド ワークロード ID を使用するメリットは次のとおりです。

  • セキュリティの強化: Workload Identity プールに参加することで、 Google Cloud ロードバランサとそのバックエンドが信頼ドメインの一部になります。バックエンド mTLS と組み合わせて使用すると、ロードバランサとバックエンド ワークロードが相互に認証を行います。この相互認証により、不正なワークロードがサービスにアクセスすることを防ぎ、転送中のデータを暗号化します。

  • 証明書の自動管理: ワークロードの構成証明が成功すると、Google Cloud は、ワークロード ID プールの信頼ドメインに参加しているワークロードの X.509 証明書を自動的にプロビジョニングしてローテーションします。X.509 証明書の自動管理により、複雑でエラーが発生しやすい手動の証明書管理プロセスが不要になります。

  • 相互運用可能な ID: ワークロード ID プールは、分散システム全体で ID を管理するための標準である SPIFFE フレームワークを使用します。これにより、最新のマイクロサービス ベースのアーキテクチャで認証と認可が可能になります。

  • 一元化されたガバナンス: Workload Identity プールは一元的な制御ポイントを提供します。管理者は信頼ドメインを定義し、証明書ポリシーを確立して、マネージド ID の X.509 証明書を受信できるワークロードを管理できます。

証明書の要件

証明書を構成する場合は、次の要件を満たしていることを確認してください。

  • mTLS 認証の基盤となるのは最新の暗号化ツールです。証明書では、鍵交換に RSA または ECDSA アルゴリズムを使用する必要があります。ハッシュ化アルゴリズムでは、SHA-256 またはより強力な暗号ハッシュ関数を使用する必要があります。MD4、MD5、SHA-1 などのハッシュ化アルゴリズムはサポートされていません。

  • バックエンドから提供されるリーフ サーバー証明書には、次の要件があります。

    • 基本制約の拡張機能には CA=true を含めないでください。
    • 鍵の拡張的用途の拡張機能には、 を含める必要があります。
    • 鍵の拡張的用途の拡張機能には、codeSigning、timeStamping、OCSPSigning フィールドを含めないでください。
    • 証明書の有効期限内である必要があります。

  • バックエンド mTLS で使用されるリーフ クライアント（ロードバランサ）証明書は、自動的に作成される Certificate Manager マネージド ID 証明書であり、次の要件を自動的に満たしている必要があります。

    • 基本制約の拡張機能には CA=true を含めないでください。
    • 鍵の拡張的用途の拡張機能には、 を含める必要があります。
    • 鍵の拡張的用途の拡張機能には、codeSigning、timeStamping、OCSPSigning フィールドを含めないでください。
    • 証明書の有効期限内である必要があります。

  • バックエンドがロードバランサに提示するサーバー証明書を認証するには、信頼構成にあるルート証明書と中間証明書が次の要件を満たしている必要があります。

    • 基本制約の拡張機能には を含める必要があります。
    • 鍵の使用の拡張機能は に設定する必要があります。
    • 鍵の拡張的用途の拡張機能には、serverAuth フィールドが含まれている必要があります。
    • 証明書の有効期限内である必要があります。

マネージド ワークロード ID を使用したバックエンド mTLS のアーキテクチャ

次のコンポーネントが連携して、マネージド ワークロード ID を使用したバックエンド mTLS を実現します。

  • ロードバランサのバックエンド サービス（Compute Engine API）
  • Identity and Access Management 信頼ドメイン（Identity and Access Management API）
  • 認証局プール（Certificate Authority Service API）
  • バックエンド認証構成（Network Security API）
  • Certificate Manager の信頼構成（Certificate Manager API）
  • Certificate Manager マネージド ID 証明書（Certificate Manager API）

次の図は、ロードバランサのバックエンド サービスでマネージド ID を使用して、ロードバランサがバックエンドに対して認証できるようにする方法を示しています。図では、ステップ 1 ～ 3 は明示的に作成されたリソースを表し、ステップ 4 ～ 5 は自動的に作成されたリソースを表しています。

  1. マネージド ワークロード ID に証明書を発行するように Certificate Authority Service CA プールを構成します。
  2. Workload Identity プールを作成して、信頼ドメインを構成します。このプールには、Namespace、マネージド ID、証明書ポリシー、インライン証明書発行構成リソース、インライン信頼構成リソースが必要です。
  3. マネージド ID を使用してロードバランサのバックエンド サービスを構成します。

  4. マネージド ワークロード ID は、Certificate Manager マネージド ID 証明書と Certificate Manager 信頼構成を自動的に作成します。

    Certificate Manager のマネージド ID 証明書は、Workload Identity プールの証明書発行構成に基づいて作成されます。Certificate Manager の信頼構成は、Workload Identity プールのインライン信頼構成と同期しています。

  5. マネージド ワークロード ID は、バックエンド認証構成を自動的に作成します。

    Certificate Manager の信頼構成がバックエンド認証構成に関連付けられています。Certificate Manager のマネージド ID 証明書（X.509-SVID）もバックエンド認証構成に関連付けられ、バックエンドに対する認証に使用されます。

マネージド ID を使用したバックエンド mTLS 構成の詳細については、マネージド ワークロード ID を使用してバックエンド mTLS を設定するをご覧ください。

マネージド ワークロード ID を使用したバックエンド mTLS。
マネージド ワークロード ID を使用したバックエンド mTLS のアーキテクチャ（クリックして拡大）

マネージド ID を使用したバックエンド mTLS の作成時に作成されるリソース

上のアーキテクチャ図に示すように、マネージド ID をバックエンド サービスに割り当てる場合、バックエンド認証構成、Certificate Manager 信頼構成、Certificate Manager 証明書を構成する必要はありません。これらのリソースは、マネージド ワークロード ID によって自動的に作成されます。

このセクションでは、マネージド ID 構成プロセスのさまざまな部分について詳しく説明します。特に、明示的に作成されるリソースと自動的に作成されるリソースに焦点を当てます。

明示的に作成されたリソース

マネージド ワークロード ID を使用してバックエンド mTLS を構成する場合は、次のリソースを明示的に作成する必要があります。

認証局プール

ロードバランサ用にマネージド ワークロード ID を構成するには、まず認証局を構成し、必要に応じて 1 つ以上の子 CA を構成する必要があります。この設定は CA 階層と呼ばれます。

この階層は CA Service プールを使用して設定できます。

Workload Identity プールは、インライン証明書発行の構成を使用して Workload Identity プールを更新することで、CA プールにバインドされます。

Workload Identity プール

マネージド ワークロード ID は、信頼ドメインとして機能する Workload Identity プール内で定義されます。

信頼ドメインは、ワークロードが SPIFFE ID を使用して相互に認証と認可を行うことができる論理的なセキュリティ境界を表します。同じ信頼ドメイン内のすべてのワークロードは共通のルート オブ トラストを共有するため、ワークロードは互いの ID を検証できます。

マネージド ID を使用するには、TRUST_DOMAIN モードで Workload Identity プールを構成する必要があります。プール内のすべての ID は、単一の名前空間と個々のワークロード識別子で構成されます。

名前空間

ワークロード ID プール内では、マネージド ワークロード ID が名前空間と呼ばれる管理境界に編成されます。名前空間は、関連するワークロード ID を整理し、アクセス権を付与するのに役立ちます。

マネージド ワークロード ID

マネージド ワークロード ID は SPIFFE 標準に準拠しています。この標準は、一意の SPIFFE ID を使用してワークロード間の通信を識別、認証、保護するためのフレームワークを提供します。

マネージド ワークロード ID またはマネージド ID は、Workload Identity プールで構成されたワークロード ID です。Google Cloud リソースに適用されます。各マネージド ID は、名前空間と個々のワークロード ID によって一意に識別されます。

バックエンド mTLS の実現というコンテキストでは、マネージド ID はロードバランサのバックエンド サービス リソースに接続されます。

マネージド ID の値は、次の形式に準拠する必要がある完全指定の SPIFFE ID です。

spiffe://TRUST_DOMAIN_NAME/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

TRUST_DOMAIN_NAME は次のように展開されます。

WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog

まとめると、ロードバランサのバックエンド サービス リソースなどの Compute Engine ワークロードには、次のようにマネージド ID を設定できます。

spiffe://WORKLOAD_IDENTITY_POOL_ID.global.PROJECT_NUMBER.workload.id.goog/ns/NAMESPACE_ID/sa/MANAGED_IDENTITY_ID

構成証明ポリシー

構成証明ポリシーには、バックエンド サービスがマネージド ID の X.509 証明書を受け取る資格があるかどうかを Google Cloud IAM が検証するためのルールが含まれています。

構成証明ポリシーの検証に合格すると、IAM は Certificate Authority Service からマネージド ID の X.509 証明書をリクエストします。X.509 証明書は、マネージド ID にバインドされている CA プールに作成されます。CA Service は、構成された SPIFFE ID が X.509 証明書に反映されるID 反映を介して証明書をプロビジョニングします。

インライン証明書発行の構成

Workload Identity プールを設定するときに、インライン証明書発行の構成を構成します。この構成では、Certificate Authority Service インスタンスのどの CA プールを使用して、Workload Identity プール内の ID の X.509 証明書を生成するかを指定します。構成ファイルでは、証明書の存続期間、ローテーション時間枠の割合、鍵アルゴリズムも指定します。

CA プールは、構成証明ポリシーの適用が成功した後に、マネージド ワークロード ID に X.509 証明書を発行します。

Workload Identity プールのインライン信頼構成

デフォルトでは、同じ信頼ドメイン内のワークロードは、マネージド ワークロード ID を使用して相互に認証できます。異なる信頼ドメインにあるワークロードを相互に認証する場合は、Workload Identity プールで信頼関係を明示的に宣言する必要があります。これを行うには、他の信頼ドメインの証明書を認識して受け入れるインライン信頼構成を作成します。これらの証明書は、信頼チェーンを構築し、他のドメインのワークロードの ID を検証するために使用されます。

インライン信頼構成には、マネージド ワークロード ID がピア証明書の検証に使用するトラスト アンカーのセットが含まれています。Certificate Manager の信頼構成は、Workload Identity プールのインライン信頼構成と同期された状態を維持する SPIFFE トラストストアをカプセル化します。

Workload Identity プールは CA プールにバインドされているため、Workload Identity プールは同じ CA プールのルート証明書を自動的に信頼します。この信頼はすでに組み込まれているため、プールの CA ルートをインライン信頼構成に追加する必要はありません。

次の図では、ロードバランサとバックエンドは同じ信頼ドメインの一部であり、同じルート証明書を共有しています。ルート証明書は、信頼チェーンを構築し、信頼ドメイン内のワークロードの ID を検証するために使用されます。

マネージド ワークロード ID リソース階層。
マネージド ワークロード ID のリソース階層（クリックして拡大）。

バックエンド サービス（Compute Engine API）

マネージド ID をロードバランサに割り当てるには、ロードバランサのバックエンド サービスを構成して、tlsSettings 属性が新しい identity プロパティ（backendService.tlsSettings.identity）を参照するようにする必要があります。

ロードバランサのバックエンド サービスで identity フィールドを使用する場合は、次の制限事項に注意してください。

  • identity プロパティを設定した場合、tlsSettings 属性の次のフィールドを手動で設定することはできません。

    • tlsSettings.sni
    • tlsSettings.subjectAltNames
    • tlsSettings.authenticationConfig

  • identity フィールドは、バックエンド サービスの作成中にのみ割り当てることができます。

  • identity フィールドは変更できません。ロードバランサのバックエンド サービスに割り当てた後は、更新または削除できません。

自動作成されたリソース

ロードバランサのバックエンド サービスで identity プロパティ（backendService.tlsSettings.identity）を設定すると、Certificate Manager API と Network Security API の次のリソースがマネージド ワークロード ID によって自動的に作成されます。

自動的に作成されるリソースは、バックエンド サービスと同じプロジェクトに作成され、そのプロジェクトの標準割り当てを使用します。

Certificate Manager の信頼構成（Certificate Manager API）

Certificate Manager の信頼構成は自動的に作成され、直接編集または削除することはできません。

Certificate Manager の信頼構成には、spiffeTrustStores というフィールドが含まれています。spiffeTrustStores フィールドには、Workload Identity プールの信頼ドメインに関連付けられた信頼バンドルと、Workload Identity プールのインライン信頼構成の additionalTrustBundles フィールドで指定された追加の信頼バンドルが含まれます。詳細については、Certificate Manager の信頼構成に spiffeTrustStores フィールドが含まれていることを確認するをご覧ください。

Certificate Manager 信頼構成の spiffeTrustStores フィールドで SPIFFE 証明書の検証を許可する方法については、サーバー証明書の検証手順をご覧ください。

Certificate Manager マネージド ID 証明書（Certificate Manager API）

Certificate Manager マネージド ID 証明書は、マネージド ワークロード ID によって自動的に作成されます。Certificate Manager のマネージド ID 証明書は読み取り専用であり、Certificate Manager API を使用して直接編集または削除することはできません。Certificate Manager のマネージド ID 証明書は、Workload Identity プールで定義されているインライン証明書発行構成に基づいています。

Certificate Manager マネージド ID 証明書には managedIdentity プロパティがあり、マネージド ID 証明書として識別されます。Certificate Manager のマネージド ID 証明書リソースには、X.509-SVID が PEM でエンコードされた形式で保存されます。この X.509-SVID には、SAN フィールドの URI としてエンコードされた SPIFFE ID が含まれています。この SPIFFE ID は、Workload Identity プールのマネージド ID に対応します。

Certificate Manager マネージド ID 証明書のスコープは CLIENT_AUTH です。これは、この証明書がバックエンド mTLS でクライアント証明書として使用されることを示します。

バックエンド認証構成（Network Security API）

バックエンド認証構成は、マネージド ワークロード ID によって自動的に作成されます。バックエンド認証構成は読み取り専用であり、Network Security API を使用して直接編集または削除することはできません。

Certificate Manager の信頼構成がバックエンド認証構成に接続されます。

Certificate Manager マネージド ID 証明書はバックエンド認証構成にも関連付けられ、ロードバランサと宛先ワークロード間のバックエンド mTLS リクエストで X.509-SVID として使用されます。

サーバー証明書の検証手順

バックエンド mTLS 中にサーバー証明書を検証するときに、ロードバランサは次の処理を行います。

  1. サーバーが証明書の秘密鍵を所有していることを確認する。

    サーバーは、秘密鍵を使用して情報に署名し、CertificateVerify メッセージの一部としてロードバランサに送信することで、ロードバランサに提示する証明書に関連付けられた秘密鍵を保持していることを証明します。ロードバランサは、サーバーの証明書の公開鍵を使用してこの署名を検証します。署名の検証に失敗した場合は、バックエンド サーバーが証明書に対応する秘密鍵を保持していないことを示します。この場合、ロードバランサはエラーをログに記録せずに TLS handshake を終了します。

  2. 信頼チェーンを検証する。

    Certificate Manager の信頼構成の spiffeTrustStores フィールドでは、SPIFFE 証明書の検証が可能です。マネージド ワークロード ID を使用すると、Certificate Manager の信頼構成の spiffeTrustStores フィールドが自動的に有効になります。spiffeTrustStores フィールドが有効になっている場合、trustStores フィールドは空のままになります。

    spiffeTrustStores フィールドは、Key-Value ペアが次のようになるマップ データ構造です。

    • キーは、Workload Identity プールに関連する信頼ドメイン（.workload.id.goog で終わる形式）と追加の信頼ドメインの両方にできます。
    • value は TrustStore オブジェクトです。このオブジェクトには、特定の信頼ドメインの SPIFFE 証明書の検証に使用される信頼できるルート証明書のコレクション（信頼バンドル）が含まれています。

    このマップを使用すると、複数の異なるセキュリティ ドメインのトラストストアを使用してロードバランサを構成できます。バックエンドが SPIFFE 証明書を提示すると、ロードバランサは SPIFFE ID を抽出し、信頼ドメインを特定して、spiffeTrustStores マップを使用して信頼チェーンの検証と証明書の検証を行うための正しいトラストストアを検索します。

    次のことが検証されます。

    • バックエンドのサーバー証明書、中間証明書（指定されている場合）、構成済みのルート証明書が証明書の要件を満たしている。
    • 信頼チェーン内のすべての証明書で、親証明書のサブジェクト フィールドが子証明書の発行元フィールドと一致している。この検証により、親証明書の ID（サブジェクト）が、子証明書の発行者としてリストされている ID と一致することが確認されます。
    • 信頼チェーン内のすべての証明書について、親証明書のサブジェクト鍵 ID（SKID）が子証明書の認証機関鍵 ID（AKID）と一致している。この一致は、子証明書が正しいルート認証機関によって発行されており、証明書の有効性を検証するために AKID でルートの公開鍵が参照されているため信頼できることを意味します。

  3. バックエンドとの接続を確立する。

    証明書の検証に成功すると、ロードバランサはバックエンドへの接続を続行します。

    ただし、証明書の検証が失敗した場合、ロードバランサはバックエンドへの接続を終了し、HTTP 502 ステータス コードをクライアントに送信すると同時に、終了理由を Cloud Logging に記録します。証明書の検証エラーが発生すると、その後の受信リクエストによってロードバランサがトリガーされ、バックエンドへの接続が再開されます。

    バックエンド サーバーが接続を拒否した場合、バックエンドへの接続に失敗することもあります。バックエンド mTLS では、クライアント証明書が無効であることが検出されたために、このエラーが発生することがあります。バックエンドへの接続に失敗すると、ロードバランサはプロキシ リクエストに HTTP 502 ステータス コードで応答し、一般的なエラーの理由を Cloud Logging に記録します。

エラー処理とロギング

アプリケーション ロードバランサには、サーバー証明書の検証のモニタリング、潜在的な問題の特定、接続の問題のトラブルシューティングを可能にする詳細なロギング機能が用意されています。このセクションでは、mTLS 検証中に発生する可能性のあるさまざまなタイプのエラーと、それらのエラーのロギング方法について説明します。

サーバー証明書の検証が失敗した場合、接続は終了し、エラーが Cloud Logging にロギングされます。次の表で、これらのエラーについて説明します。

サーバー証明書のステータス ロギングされたエラー
サーバー証明書チェーンが長すぎる（サーバー証明書に 10 を超える中間証明書が含まれる）。 server_cert_chain_exceeded_limit

サーバーまたは中間証明書の RSA 鍵のサイズが無効。

検証は実行されません。

RSA 鍵の長さは 2,048～4,096 ビットです。

 server_cert_invalid_rsa_key_size

サーバー証明書または中間証明書で、サポートされていない楕円曲線が使用されている。

検証は実行されません。

有効な曲線は P-256 と P-384 です。

 server_cert_unsupported_elliptic_curve_key

サーバー証明書または中間証明書が、非 RSA または ECDSA 以外のアルゴリズムを使用している。

検証は実行されません。

 server_cert_unsupported_key_algorithm

検証に使用する PKI に、同じサブジェクトとサブジェクトの公開鍵情報を共有する 11 個以上の中間証明書がある。

検証は実行されません。

 server_cert_pki_too_large

検証に指定された中間証明書に 10 を超える名前の制約がある。

server_cert_chain_max_name_constraints_exceeded

サーバー証明書に Extended Key Usage (EKU) 拡張フィールドがあるが、そのフィールドに serverAuth が含まれていない。

server_cert_chain_invalid_eku
証明書チェーンの検証中に制限時間を超過した。 server_cert_validation_timed_out

証明書チェーンの検証中に、深度または反復処理の上限に達した。

証明書チェーンの最大深度は、ルート証明書とサーバー証明書を含めて 10 です。反復処理の上限は 100 回です（サーバー証明書チェーンの検証のために確認された証明書）。

 server_cert_validation_search_limit_exceeded

TrustConfig リソースを設定せずに mTLS を構成した。

 server_cert_validation_not_performed

サーバーが handshake 中にリクエストされた証明書を提示しなかった。

 server_cert_not_provided

サーバー証明書が TrustConfig リソースでの検証に失敗しました。

 ssl_certificate_verification_failed

サービスで証明書チェーンの検証を実行できない。

 server_cert_validation_unavailable
証明書チェーンの検証中に内部エラーが発生した。 server_cert_validation_internal_error

一致する TrustConfig が見つからない。

 server_cert_trust_config_not_found
サーバー証明書のペイロード（中間証明書を含む）が大きすぎる（16 KB 超）。 server_cert_exceeded_size_limit

制限事項

  • マネージド ワークロード ID を使用したバックエンド mTLS は、グローバル外部アプリケーション ロードバランサでのみ構成できます。従来のアプリケーション ロードバランサは、バックエンド mTLS をサポートしていません。

  • バックエンド mTLS は、グローバル インターネット NEG バックエンドではサポートされていません。

  • マネージド ID をバックエンド サービス（backendService.tlsSettings.identity）に割り当てた場合、バックエンド サービスの tlsSettings プロパティで次のフィールドを手動で設定することはできません。

    • backendService.tlsSettings.sni
    • backendService.tlsSettings.subjectAltNames
    • backendService.tlsSettings.authenticationConfig

  • マネージド ID を割り当てることができるのは、バックエンド サービスの作成時のみです。

  • マネージド ID は変更できません。マネージド ID をロードバランサのバックエンド サービスに割り当てた後は、更新または削除できません。

次のステップ