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

バックエンド mTLS は、マネージドワークロード ID の有無にかかわらず実現できます。マネージドワークロード 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: Namespace ID
MANAGED_IDENTITY_ID: マネージド ID の ID

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

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

セキュリティの強化: ワークロード ID プールに参加することで、 Google Cloud ロードバランサとそのバックエンドが信頼ドメインの一部になります。バックエンド mTLS と組み合わせて使用すると、ロードバランサとバックエンドワークロードが相互に認証を行います。この相互認証により、不正なワークロードがサービスにアクセスすることを防ぎ、転送中のデータを暗号化します。
証明書の自動管理: ワークロードの構成証明が成功すると、Google Cloud はワークロード ID プールの信頼ドメインに参加しているワークロードの X.509 証明書を自動的にプロビジョニングしてローテーションします。X.509 証明書の自動管理により、複雑でエラーが発生しやすい手動の証明書管理プロセスが不要になります。
相互運用可能な ID: ワークロード ID プールは、分散システム全体で 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 は自動的に作成されたリソースを表しています。

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

Certificate Manager のマネージド ID 証明書は、Workload Identity プールの証明書発行構成に基づいて作成されます。Certificate Manager の信頼構成は、Workload Identity プールのインライン信頼構成と同期しています。
マネージドワークロード ID は、バックエンド認証構成を自動的に作成します。

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

マネージド 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 プールにバインドされます。

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

ワークロード ID プールの名前空間にマネージドワークロード ID を作成する必要があります。マネージド ID は、ロードバランサワークロードによって提示される SVID で使用される完全指定の SPIFFE ID です。

構成証明ポリシー

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

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

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

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

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

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

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

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

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

バックエンドサービス（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 フィールドには、ワークロード ID プールの信頼ドメインに関連付けられた信頼バンドルと、ワークロード ID プールのインライン信頼構成の additionalTrustBundles フィールドで指定された追加の信頼バンドルが含まれます。

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

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

キーは、Workload Identity プールに関連する信頼ドメイン（.workload.id.goog で終わる形式）と追加の信頼ドメインの両方にできます。
value は 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 をサポートしていません。
バックエンド mTLS は、グローバルインターネット NEG バックエンドではサポートされていません。
マネージド ID をバックエンドサービス（backendService.tlsSettings.identity）に割り当てると、バックエンドサービスの tlsSettings プロパティで次のフィールドを手動で設定することはできません。
- backendService.tlsSettings.sni
- backendService.tlsSettings.subjectAltNames
- backendService.tlsSettings.authenticationConfig
マネージド ID を割り当てることができるのは、バックエンドサービスの作成時のみです。
マネージド ID は変更できません。マネージド ID をロードバランサのバックエンドサービスに割り当てた後は、更新または削除できません。

次のステップ

マネージドワークロード ID を使用してバックエンド mTLS を設定する