ユーザー指定の証明書を使用してフロントエンド mTLS を設定する

有効なクライアント証明書には、トラストストア内のトラスト アンカー（ルート証明書）に至る信頼チェーンが含まれている必要があります。このページでは、OpenSSL ライブラリを使用して独自のルート証明書と中間証明書を構成し、独自の信頼チェーンを作成する手順について説明します。

このドキュメントでは、ルート オブ トラストを作成した後、Certificate Manager TrustConfig リソースのトラストストアにアップロードするプロセスについて説明します。次に、信頼構成をクライアント認証（ServerTLSPolicy）リソースにリンクし、クライアント認証リソースをロードバランサのターゲット HTTPS プロキシ リソースに接続します。

始める前に

• 相互 TLS の概要を確認します。
• 信頼構成を管理するのガイドを確認します。

• Google Cloud CLI をインストールします。ツールの完全な概要については、gcloud CLI の概要をご覧ください。ロード バランシングに関連するコマンドについては、API と gcloud CLI のリファレンスをご覧ください。

  gcloud CLI を初めて実行する場合は、最初に gcloud init コマンドを実行して、認証を行います。

• Compute Engine API、Certificate Manager API、ネットワーク セキュリティ、Network Services API の API を有効にします。詳細については、API を有効にするをご覧ください。

• グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサを使用している場合は、次のサポート対象のバックエンドのいずれかでロードバランサが設定されていることを確認してください。

  • VM インスタンス グループのバックエンド
  • Cloud Storage バケット（バックエンド バケットに加えて、ロードバランサに接続されているバックエンド サービスが 1 つ以上ある場合にのみサポートされます）
  • Cloud Run、App Engine、または Cloud Run functions
  • ハイブリッド接続
  • Private Service Connect バックエンド

• リージョン外部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサ、またはリージョン内部アプリケーション ロードバランサを使用している場合は、次のいずれかのサポート対象のバックエンドを使用してロードバランサが設定されていることを確認します。

  • VM インスタンス グループのバックエンド
  • Cloud Run
  • ハイブリッド接続
  • Private Service Connect バックエンド

• プロジェクトを設定します。

  gcloud

  gcloud config set project PROJECT_ID
  

権限

このガイドで必要になる権限を取得するには、プロジェクトに対する次の IAM ロールを付与するよう管理者に依頼してください。

• TargetHTTPSProxy などのロードバランサ リソースの作成: Compute ロードバランサ管理者（roles/compute.loadBalancerAdmin）
• Certificate Manager リソースの使用: Certificate Manager オーナー（roles/certificatemanager.owner）
• セキュリティとネットワーキングのコンポーネントの作成: Compute ネットワーク管理者（roles/compute.networkAdmin）および Compute セキュリティ管理者（roles/compute.securityAdmin）
• プロジェクトの作成（任意）: プロジェクト作成者（roles/resourcemanager.projectCreator）

ロールの付与については、プロジェクト、フォルダ、組織に対するアクセス権の管理をご覧ください。

必要な権限は、カスタムロールや他の事前定義ロールから取得することもできます。

注: IAM の基本ロールに、このガイドを完了するために必要な権限も含まれている場合があります。本番環境では基本ロールを付与すべきではありません。基本ロールは、開発環境またはテスト環境で付与してください。

ルート証明書と中間証明書を作成する

注:

トラストストアにアップロードする証明書がすでにある場合は、この手順をスキップして、証明書をフォーマットするに進みます。

自己署名証明書、期限切れの証明書、その他の無効な証明書を使用する必要がある場合、またはルート証明書と中間証明書を使用できない場合は、自己署名証明書を作成して、信頼構成の許可リストに追加できます。

このセクションでは、OpenSSL ライブラリを使用して、ルート証明書（トラスト アンカー）と中間証明書を作成します。

ルート証明書は証明書チェーンの最上位にあります。中間証明書は、ルート証明書まで遡る信頼チェーンの一部です。中間証明書は、ルート証明書によって暗号署名されます。ロードバランサは、クライアント証明書を受信すると、クライアント証明書から構成済みのトラスト アンカーまでの信頼チェーンを確立して、証明書を検証します。

次のコマンドを使用して、ルート証明書と中間証明書を作成します。中間証明書の作成は任意です。ただし、この設定では、中間証明書を使用してクライアント証明書に署名しています。

1. OpenSSL 構成ファイルを作成します。

   次の例の構成ファイル（example.cnf）には、[ca_exts] セクションが含まれています。このセクションには、証明書を CA に適したものとしてマークする X.509 拡張機能が指定されています。ルート証明書と中間証明書の要件の詳細については、証明書の要件をご覧ください。

   cat > example.cnf << EOF
   [req]
   distinguished_name = empty_distinguished_name
   
   [empty_distinguished_name]
   # Kept empty to allow setting via -subj command-line argument.
   
   [ca_exts]
   basicConstraints=critical,CA:TRUE
   keyUsage=keyCertSign
   extendedKeyUsage=clientAuth
   
   EOF
   

2. 自己署名 X.509 ルート証明書（root.cert）を作成します。ルート証明書は、独自の秘密鍵（root.key）で自己署名されます。

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=root' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout root.key -out root.cert
   

3. 中間証明書の証明書署名リクエスト（int.req）を作成します。

   openssl req -new \
       -sha256 -newkey rsa:2048 -nodes \
       -subj '/CN=int' \
       -config example.cnf \
       -extensions ca_exts \
       -keyout int.key -out int.req
   

4. CSR に署名して X.509 中間証明書（int.cert）を作成します。CSR はルート証明書を使用して署名されます。

   openssl x509 -req \
       -CAkey root.key -CA root.cert \
       -set_serial 1 \
       -days 3650 \
       -extfile example.cnf \
       -extensions ca_exts \
       -in int.req -out int.cert
   

許可リストに追加できる自己署名証明書を作成する

注:

トラストストアにアップロードする証明書がすでにある場合は、この手順をスキップして、証明書をフォーマットするに進みます。

自己署名証明書を作成して、信頼構成の許可リストに追加できます。

次の OpenSSL コマンドを使用して、自己署名 X.509 証明書を作成します。

   openssl req -x509 \
       -new -sha256 -newkey rsa:2048 -nodes \
       -days 3650 -subj '/CN=localhost' \
       -keyout allowlisted.key -out allowlisted.cert

この証明書は、信頼構成の allowlistedCertificates フィールドに追加されます。

証明書をフォーマットする

新規または既存の証明書を TrustStore に含めるには、証明書を 1 行にまとめて環境変数に格納し、信頼構成 YAML ファイルで参照できるようにします。

export ROOT_CERT=$(cat root.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

export INTERMEDIATE_CERT=$(cat int.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

許可リストに追加された新規または既存の証明書を信頼構成に配置するには、YAML ファイルに読み込めるように、証明書を 1 行にまとめて環境変数に格納します。許可リストに登録されている証明書の場合は、次のコマンドを使用して、証明書を 1 行にまとめて ALLOWLISTED_CERT 環境変数に格納します。

export ALLOWLISTED_CERT=$(cat allowlisted.cert | sed 's/^[ ]*//g' | tr '\n' $ | sed 's/\$/\\n/g')

信頼構成リソースを作成する

信頼構成は、Certificate Manager の公開鍵基盤（PKI）構成を表すリソースです。

信頼構成リソースを作成するには、次の手順を行います。

コンソール

1. Google Cloud コンソールで、[Certificate Manager] ページに移動します。

   [Certificate Manager] に移動

2. [信頼構成] タブで、[信頼構成を追加] をクリックします。

3. 構成の名前を入力します。

4. [ロケーション] で、[グローバル] または [リージョン] を選択します。

   ロケーションは、信頼構成リソースが保存される場所を示します。グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、グローバル信頼構成リソースを作成します。リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、リージョン信頼構成リソースを作成します。

   [リージョン] を選択した場合は、リージョンを選択します。

5. [トラストストア] セクションで、[トラスト アンカーを追加] をクリックし、PEM エンコードの証明書ファイルをアップロードするか、証明書の内容をコピーします。

6. [追加] をクリックします。

7. [トラストストア] セクションで、[中間 CA の追加] をクリックし、PEM エンコードの証明書ファイルをアップロードするか、証明書の内容をコピーします。

   この手順により、ルート証明書とサーバー証明書の間に別の信頼レベルを追加できます。

8. [追加] をクリックして、中間 CA を追加します。

9. 省略可: [許可リストに登録済みの証明書] セクションで、[証明書を追加] をクリックし、PEM でエンコードされた証明書ファイルをアップロードするか、証明書の内容をコピーします。

10. [追加] をクリックして、許可リストに登録済みの証明書を追加します。

11. [作成] をクリックします。

新しい信頼構成リソースが構成のリストに表示されていることを確認します。

gcloud

1. 信頼構成パラメータを指定する信頼構成 YAML ファイル（trust_config.yaml）を作成します。この信頼構成リソースの例には、トラスト アンカーと中間証明書を含むトラストストアが含まれています。前の証明書をフォーマットするの手順で作成した環境変数から証明書の内容を読み取ります。

   cat << EOF > trust_config.yaml
   trustStores:
   - trustAnchors:
     - pemCertificate: "${ROOT_CERT?}"
     intermediateCas:
     - pemCertificate: "${INTERMEDIATE_CERT?}"
   EOF
   

   追加のトラスト アンカーまたは中間証明書を使用してトラストストアを作成するには、適切なセクションに pemCertificate 行を追加します。

2. 省略可: 信頼構成 YAML ファイルに追加する証明書を allowlistedCertificates フィールドに指定します。証明書を許可リストに追加するためにトラストストアは必要ありません。

   cat << EOF >> trust_config.yaml
   allowlistedCertificates:
   - pemCertificate: "${ALLOWLISTED_CERT?}"
   EOF
   

   許可リストに追加された証明書は、信頼構成内でカプセル化可能なあらゆる証明書を表し、常に有効と見なされます。pemCertificate フィールドの複数のインスタンスを使用して、許可リストの複数の証明書を指定できます。

3. 信頼構成 YAML ファイルをインポートするには、gcloud certificate-manager trust-configs import コマンドを使用します。

   グローバル

   グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、信頼構成リソースの保存場所として global を指定します。

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=global
   

   次のように置き換えます。

   • TRUST_CONFIG_NAME: 信頼構成リソースの名前。

   リージョン

   リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、信頼構成リソースの保存場所としてリージョンを指定します。

   gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME  \
       --source=trust_config.yaml \
       --location=LOCATION
   

   次のように置き換えます。

   • TRUST_CONFIG_NAME: 信頼構成リソースの名前。
   • LOCATION: 信頼構成リソースが保存されるリージョン。デフォルトの場所は global です。

クライアント認証リソースを作成する

クライアント認証（ServerTLSPolicy とも呼ばれます）リソースを使用すると、クライアント証明書の検証で使用するサーバーサイド TLS モードと信頼構成リソースを指定できます。クライアントがロードバランサに無効な証明書を提示するか、証明書を提示しない場合は、clientValidationMode でクライアント接続の処理方法を指定します。詳細については、mTLS クライアント検証モードをご覧ください。

• clientValidationMode が ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている場合、検証が失敗した場合やクライアント証明書が欠落していても、すべてのリクエストがバックエンドに渡されます。
• clientValidationMode が REJECT_INVALID に設定されている場合、TrustConfig リソースの検証が可能なクライアント証明書を提示するリクエストのみがバックエンドに渡されます。

クライアント認証（ServerTlsPolicy）リソースを作成するには、次の操作を行います。

コンソール

1. Google Cloud コンソールで、[認証構成] ページに移動します。

   [認証構成] に移動

2. [クライアント認証] タブで [作成] をクリックします。

3. クライアント認証リソースの名前を入力します。

4. [ロケーション] で、[グローバル] または [リージョン] を選択します。

   グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、ロケーションをグローバルに設定します。リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、ロケーションをロードバランサが構成されているリージョンに設定します。

5. [クライアント認証モード] で [ロード バランシング] を選択します。

6. クライアント検証モードを選択します。

7. 前に作成した信頼構成リソースを選択します。

8. [作成] をクリックします。

クライアント認証（ServerTlsPolicy）が表示されていることを確認します。

gcloud

1. 接続の処理方法に応じて、次のいずれかのオプションを選択し、クライアント認証（ServerTlsPolicy）リソースを YAML 形式で定義します。

   • オプション 1: clientValidationMode が ALLOW_INVALID_OR_MISSING_CLIENT_CERT に設定されている。

     グローバル

     グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     リージョン

     リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとリージョン信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: ALLOW_INVALID_OR_MISSING_CLIENT_CERT
         clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

   • オプション 2: clientValidationMode が REJECT_INVALID に設定されている。

     グローバル

     グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
         clientValidationMode: REJECT_INVALID
         clientValidationTrustConfig: projects/PROJECT_ID/locations/global/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     リージョン

     リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとリージョン信頼構成リソースを宣言的に指定する YAML ファイルを作成します。

     cat << EOF > server_tls_policy.yaml
     name: SERVER_TLS_POLICY_NAME
     mtlsPolicy:
           clientValidationMode: REJECT_INVALID
           clientValidationTrustConfig: projects/PROJECT_ID/locations/REGION/trustConfigs/TRUST_CONFIG_NAME
     EOF
     

     次のように置き換えます。

     SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

     PROJECT_ID: Google Cloud プロジェクトの ID。

     LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

     TRUST_CONFIG_NAME: 前に作成した信頼構成リソースの名前。

2. クライアント認証 ServerTlsPolicy リソースをインポートするには、gcloud network-security server-tls-policies import コマンドを使用します。

   グローバル

   グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、--location フラグを global に設定します。

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=global
   

   次のように置き換えます。

   SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

   リージョン

   リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、--location フラグをロードバランサが構成されているリージョンに設定します。

   gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \
     --source=server_tls_policy.yaml \
     --location=LOCATION
   

   次のように置き換えます。

   SERVER_TLS_POLICY_NAME: クライアント認証（ServerTlsPolicy）リソースの名前。

3. 省略可: すべてのクライアント認証（ServerTlsPolicies）リソースを一覧取得するには、gcloud network-security server-tls-policies list コマンドを使用します。

   gcloud network-security server-tls-policies list \
     --location=LOCATION
   

   次のように置き換えます。

   LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

注: クライアント認証（ServerTlsPolicy）リソースを変更するには、まず既存のクライアント認証リソースを削除してから、新しいクライアント認証リソースを作成する必要があります。その後、クライアント認証リソースをロードバランサのターゲット HTTPS プロキシに接続できます。

クライアント認証リソースをロードバランサに接続する

相互 TLS 認証を機能させるには、ロードバランサを設定した後、クライアント認証（ServerTLSPolicy）リソースをロードバランサのターゲット HTTPS プロキシ リソースに接続する必要があります。

コンソール

1. Google Cloud コンソールで、[ロード バランシング] ページに移動します。

   [ロード バランシング] に移動

2. ロードバランサのリストから、クライアント認証（ServerTLSPolicy）リソースを接続するロードバランサを選択します。

3. [編集] をクリックします。

4. HTTPS フロントエンドの [フロントエンドの構成] セクションで、[高度な機能の表示] セクションを開きます。

5. [クライアント認証] リストから、クライアント認証リソースを選択します。

6. [完了] をクリックします。

7. [更新] をクリックします。

gcloud

1. プロジェクト内のすべてのターゲット HTTPS プロキシ リソースを一覧取得するには、gcloud compute target-https-proxies list コマンドを使用します。

   gcloud compute target-https-proxies list
   

   ServerTLSPolicy リソースを接続するターゲット HTTPS プロキシの名前をメモします。以降のステップでは、この名前を TARGET_HTTPS_PROXY_NAME として表しています。

2. ターゲット HTTPS プロキシの構成をファイルにエクスポートするには、gcloud compute target-https-proxies export コマンドを使用します。

   グローバル

     gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
         --destination=TARGET_PROXY_FILENAME \
         --global
     

   次のように置き換えます。

   • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
   • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml

   リージョン

   gcloud compute target-https-proxies export TARGET_HTTPS_PROXY_NAME \
       --destination=TARGET_PROXY_FILENAME \
       --region=REGION
   

   次のように置き換えます。

   • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
   • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml
   • REGION: ロードバランサを構成したリージョン。

3. すべてのクライアント認証（ServerTlsPolicy）リソースを一覧取得するには、gcloud network-security server-tls-policies list コマンドを使用します。

   gcloud network-security server-tls-policies list \
       --location=LOCATION
   

   次のように置き換えます。

   LOCATION: クロスリージョン内部アプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、または従来のアプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

   mTLS を構成するクライアント認証（ServerTLSPolicy）リソースの名前をメモします。次のステップでは、この名前を SERVER_TLS_POLICY_NAME と表しています。

4. クライアント認証（ServerTlsPolicy）をターゲット HTTPS プロキシに追加します。

   echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/LOCATION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME

   次のように置き換えます。

   • PROJECT_ID: 実際の Google Cloud プロジェクト ID。
   • LOCATION: グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、global を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。
   • SERVER_TLS_POLICY_NAME: クライアント認証（ServerTLSPolicy）リソースの名前。
   • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。

5. ターゲット HTTPS プロキシの構成をファイルからインポートするには、gcloud compute target-https-proxies import コマンドを使用します。

   グローバル

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --global
     

   次のように置き換えます。

   • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
   • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml

   リージョン

     gcloud compute target-https-proxies import TARGET_HTTPS_PROXY_NAME \
         --source=TARGET_PROXY_FILENAME \
         --region=REGION
     

   次のように置き換えます。

   • TARGET_HTTPS_PROXY_NAME: ターゲット プロキシの名前。
   • TARGET_PROXY_FILENAME: ターゲット プロキシの構成ファイルの名前（YAML 形式）。例: mtls_target_proxy.yaml
   • REGION: ロードバランサを構成したリージョン。

mTLS カスタム ヘッダーを追加する

mTLS を有効にすると、カスタム ヘッダーを使用して mTLS 接続に関する情報を渡すことができます。また、ロギングを有効にして、mTLS 接続エラーをログにキャプチャすることもできます。

バックエンド サービスに mTLS カスタム ヘッダーを追加する

グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合、カスタム ヘッダーを使用して mTLS 接続に関する情報をバックエンド サービスに渡すことができます。

1. プロジェクト内のすべてのバックエンド サービスを一覧取得するには、gcloud compute backend-services list コマンドを使用します。

   gcloud compute backend-services list
   

   カスタム ヘッダーとロギングを有効にするため、バックエンド サービスの名前をメモします。この名前は、次のステップで BACKEND_SERVICE として参照されます。

2. バックエンド サービスを更新するには、gcloud compute backend-services update コマンドを使用します。

   gcloud compute backend-services update BACKEND_SERVICE \
     --global \
     --enable-logging \
     --logging-sample-rate=1 \
     --custom-request-header='X-Client-Cert-Present:{client_cert_present}' \
     --custom-request-header='X-Client-Cert-Chain-Verified:{client_cert_chain_verified}' \
     --custom-request-header='X-Client-Cert-Error:{client_cert_error}' \
     --custom-request-header='X-Client-Cert-Hash:{client_cert_sha256_fingerprint}' \
     --custom-request-header='X-Client-Cert-Serial-Number:{client_cert_serial_number}' \
     --custom-request-header='X-Client-Cert-SPIFFE:{client_cert_spiffe_id}' \
     --custom-request-header='X-Client-Cert-URI-SANs:{client_cert_uri_sans}' \
     --custom-request-header='X-Client-Cert-DNSName-SANs:{client_cert_dnsname_sans}' \
     --custom-request-header='X-Client-Cert-Valid-Not-Before:{client_cert_valid_not_before}' \
     --custom-request-header='X-Client-Cert-Valid-Not-After:{client_cert_valid_not_after}'
   

注:

独自のカスタム ヘッダーの名前を指定できます。--custom-request-header オプションで使用されている名前はあくまでも例です。

mTLS カスタム ヘッダーの一部またはすべてを有効にできます。

mTLS カスタム ヘッダーを URL マップに追加する

クロスリージョン内部アプリケーション ロードバランサ、リージョン外部アプリケーション ロードバランサ、リージョン内部アプリケーション ロードバランサの場合は、カスタム ヘッダーを使用して mTLS 接続に関する情報を URL マップに渡すことができます。

プロジェクト内のすべての URL マップを一覧取得するには、gcloud compute url-maps list コマンドを使用します。

   gcloud compute url-maps list
   

カスタム ヘッダーとロギングを有効にするために、URL マップの名前をメモします。次のステップでは、この名前を URL_MAP_NAME と表しています。

グローバル

クロスリージョン内部アプリケーション ロードバランサの URL マップを編集するには、gcloud compute url-maps edit コマンドを使用します。

   gcloud compute url-maps edit URL_MAP_NAME --global
   

以下に、カスタム リクエスト ヘッダー（requestHeadersToAdd）で変数を使用する方法を示す YAML ファイルの例を示します。同じ変数を使用して、カスタム レスポンス ヘッダー（responseHeadersToAdd）を送信できます。

   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

リージョン

リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサの URL マップを編集するには、gcloud compute url-maps edit コマンドを使用します。

   gcloud compute url-maps edit URL_MAP_NAME --region=REGION
   

以下に、カスタム リクエスト ヘッダー（requestHeadersToAdd）で変数を使用する方法を示す YAML ファイルの例を示します。同じ変数を使用してカスタム レスポンス ヘッダー（responseHeadersToAdd）を送信できます。

   defaultService: regions/REGION/backendServices/BACKEND_SERVICE_1
      name: regional-lb-map
      region: region/REGION
   headerAction:
      requestHeadersToAdd:
      - headerName: "X-Client-Cert-Present"
        headerValue: "{client_cert_present}"
      - headerName: "X-Client-Cert-Chain-Verified"
        headerValue: "{client_cert_chain_verified}"
      - headerName: "X-Client-Cert-Error"
        headerValue: "{client_cert_error}"
      - headerName: "X-Client-Cert-Hash"
        headerValue: "{client_cert_sha256_fingerprint}"
      - headerName: "X-Client-Cert-Serial-Number"
        headerValue: "{client_cert_serial_number}"
      - headerName: "X-Client-Cert-SPIFFE"
        headerValue: "{client_cert_spiffe_id}"
      - headerName: "X-Client-Cert-URI-SANs"
        headerValue: "{client_cert_uri_sans}"
      - headerName: "X-Client-Cert-DNSName-SANs"
        headerValue: "{client_cert_dnsname_sans}"
      - headerName: "X-Client-Cert-Valid-Not-Before"
        headerValue: "{client_cert_valid_not_before}"
      - headerName: "X-Client-Cert-Valid-Not-After"
        headerValue: "{client_cert_valid_not_after}"
      - headerName: "X-Client-Cert-Issuer-Dn"
        headerValue: "{client_cert_issuer_dn}"
      - headerName: "X-Client-Cert-Subject-Dn"
        headerValue: "{client_cert_subject_dn}"
      - headerName: "X-Client-Cert-Leaf"
        headerValue: "{client_cert_leaf}"
      - headerName: "X-Client-Cert-Chain"
        headerValue: "{client_cert_chain}"
   

中間証明書を使用してクライアント証明書に署名する

このセクションでは、クライアント（リーフ）証明書を生成するための追加の構成オプションについて説明します。中間証明書を含むTrustConfig リソースをすでに作成している場合は、次の操作を行います。

1. 構成ファイルを作成して、クライアント証明書の CSR を生成します。

   次の構成ファイル（client.config）には、CSR に含める X.509 拡張機能を指定する [extension_requirements] セクションが含まれています。クライアント証明書の要件の詳細については、証明書の要件をご覧ください。

   注: キーがサーバーで使用されている場合は、serverAuth を extendedKeyUsage フィールドに追加できます。

   cat > client.config << EOF
   [req]
   default_bits              = 2048
   req_extensions            = extension_requirements
   distinguished_name        = dn_requirements
   prompt                    = no
   
   [extension_requirements]
   basicConstraints          = critical, CA:FALSE
   keyUsage                  = critical, nonRepudiation, digitalSignature, keyEncipherment
   extendedKeyUsage          = clientAuth
   
   [dn_requirements]
   countryName               = US
   stateOrProvinceName       = California
   localityName              = San Francisco
   0.organizationName        = example
   organizationalUnitName    = test
   commonName                = test.example.com
   emailAddress              = [e-mail]
   
   EOF
   

   SPIFFE ID を構成ファイルに関連付けるには、次の操作を行います。

   • 次のように、[extension_requirements] セクションに subjectAltName フィールドを追加します。

     subjectAltName            = @sans_list
     

   • client.config ファイルの下部に、次のように新しいセクション（[sans_list]）を追加します。

     [sans_list]
     URI.1                     = spiffe://example.com/test-identity
     

2. クライアント証明書の CSR（client.csr）を作成します。

   openssl req -new \
       -config client.config \
       -keyout client.key -out client.csr
   

3. CSR に署名して X.509 クライアント証明書（client.cert）を発行します。CSR は中間証明書によって署名されます。

   openssl x509 -req \
       -CAkey int.key -CA int.cert \
       -days 365 \
       -extfile client.config \
       -extensions extension_requirements \
       -in client.csr -out client.cert
   

4. クライアントサイドの SSL 証明書を使用して、ロードバランサの IP アドレスに安全な HTTPS リクエストを送信します。クライアントは、認証を受けるために自身の証明書（client.cert）をロードバランサに提示します。

   curl -v --key client.key --cert client.cert https://IP_ADDRESS
   

   IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。

次のステップ

• プライベート CA による相互 TLS を設定する