ユーザー指定の証明書を使用して相互 TLS を設定する

このページでは、ルート証明書と署名付きの中間証明書を作成し、それらの証明書を Certificate Manager TrustConfig リソースにアップロードする手順を説明します。アップロードする証明書がすでにある場合は、新しい証明書を作成する手順をスキップします。

また、アプリケーション ロードバランサの相互 TLS（mTLS）を構成に必要なネットワーク セキュリティ リソースも作成します。この手順では、OpenSSL を使用してルート証明書と中間証明書を作成します。

始める前に

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

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

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

  • API を有効にします。Compute Engine API、Certificate Manager API、ネットワーク セキュリティ、Network Services API を有効にします。

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

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

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

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

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

    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）

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

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

鍵と署名済み証明書を生成する

このセクションでは、openssl コマンドを使用してルート証明書と中間証明書を作成します。

ルート証明書と、有効な keyUsage フィールドと extendedKeyUsage フィールドを含む署名付き中間証明書を生成するには、次のコマンドを使用します。

  1. 有効な署名証明書を作成するために必要な最小限の構成を含むサンプルの example.cnf ファイルを作成します。これらの証明書に追加のフィールドを設定する場合は、このファイルを編集できます。

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

  2. ルート証明書を作成します。

    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. 中間証明書の署名リクエストを作成します。

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

  4. 中間証明書を作成します。

    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 コマンドを使用してサンプル証明書を作成し、許可リストに追加します。

次のコマンドを使用して証明書を生成して許可リストに追加します。

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

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

新規または既存の証明書を TrustStore に含めるには、YAML ファイルに読み込めるように、証明書を 1 行にまとめて環境変数に格納します。次のコマンドを使用して、証明書をフォーマットし、環境変数に格納します。

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 を使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。

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

相互 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}'

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}"

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

このセクションでは、リーフ証明書を生成するための追加の構成オプションについて説明します。中間証明書（int.cert と int.key）を使用してすでに TrustConfig リソースを作成している場合は、次の操作を行います。

  1. クライアント キー構成ファイルを作成します。

    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              = test@example.com

EOF

    SPIFFE ID が関連付けられている場合:

    • 次のように subjectAltName を [extension_requirements] セクションに追加します。

      subjectAltName            = @sans_list

    • client.config ファイルの下部に、次の内容の新しいセクションを追加します。

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

  2. 鍵に署名します。

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

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

  3. テストするために、ロードバランサの IP アドレスに curl リクエストを送信します。

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

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

次のステップ