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

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

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

このドキュメントの情報は、次のドキュメントで説明されている概念に基づいています。

ロードバランサのマネージド ワークロード 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: 名前空間 ID
  • MANAGED_IDENTITY_ID: マネージド ID の ID

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

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

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

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

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

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

マネージド ワークロード 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 プールを作成して、信頼ドメインを構成します。 このプールには、名前空間、マネージド 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 を使用するには、Workload Identity プールを TRUST_DOMAIN モードで構成する必要があります。プール内のすべての ID は、単一の名前空間と個々のワークロード識別子で構成されます。

名前空間

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

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

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

マネージド ワークロード ID またはマネージド ID は、Workload Identity プールで構成されるワークロード識別子です。 リソースに関連付けられています。Google Cloud 各マネージド 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 は、 ID リフレクションを介して証明書をプロビジョニングします 。この場合、構成された SPIFFE ID が X.509 証明書に反映されます。

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

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

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

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

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

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

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 フィールド で指定された追加の信頼バンドルが含まれています。

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

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

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

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

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 として使用されます。

制限事項

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

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

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

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

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

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

次のステップ