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

有効なクライアント証明書には、トラストストア内のトラスト アンカー（ルート証明書）に遡る信頼チェーンが示されている必要があります。このページでは、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 関数
    • ハイブリッド接続

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

    • 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 ライブラリを使用して、ルート証明書（信頼アンカー）と中間証明書を作成します。

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

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

  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 arg.

[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 に含めるには、信頼構成 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. [Trust Configs] タブで、[Add Trust Config] をクリックします。

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

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

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

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

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

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

  7. [Trust store] セクションで、[Add intermediate 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

    グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、信頼構成リソースの保存場所として 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. [Client Authentication mode] で [Load balancing] を選択します。

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

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

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

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

gcloud

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

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

      global

      グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する 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 に設定されている。

      global

      グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、クライアント検証モードとグローバル信頼構成リソースを宣言的に指定する 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 コマンドを使用します。

    global

    グローバル外部アプリケーション ロードバランサ、従来のアプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサの場合は、--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. [Client Authentication] リストから、Client Authentication リソースを選択します。

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

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

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

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

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

    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 を構成ファイルに関連付けるには、次の操作を行います。

    • 次のように、[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 アドレスに置き換えます。

次のステップ