このページでは、ルート証明書と署名付きの中間証明書を作成し、それらの証明書を 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 関数
- ハイブリッド接続
リージョン外部アプリケーション ロードバランサ、クロスリージョン内部アプリケーション ロードバランサ、またはリージョン内部アプリケーション ロードバランサを使用している場合は、次のいずれかのサポート対象のバックエンドを使用してロードバランサが設定されていることを確認します。
- 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 フィールドを含む署名付き中間証明書を生成するには、次のコマンドを使用します。
有効な署名証明書を作成するために必要な最小限の構成を含むサンプルの
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ルート証明書を作成します。
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中間証明書の署名リクエストを作成します。
openssl req \ -new -sha256 -newkey rsa:2048 -nodes \ -subj '/CN=int' \ -config example.cnf \ -extensions ca_exts \ -keyout int.key -out int.req中間証明書を作成します。
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')
TrustConfig リソースを作成する
PKI を表す Certificate Manager TrustConfig リソースを作成します。この TrustConfig リソースには、2 つの信頼アンカーと 2 つの中間 CA 証明書のあるトラストストアが含まれています。前の証明書をフォーマットするの手順で作成した環境変数から証明書の内容を読み取ります。
追加のトラスト アンカーまたは中間 CA 証明書を使用してトラストストアを作成するには、適切なセクションに pemCertificate 行を追加します。トラスト アンカーまたは中間 CA 証明書の数が少ない場合は、不要な行を削除します。
この例の TrustConfig リソースには、許可リストに追加された証明書が含まれています。pemCertificate フィールドの複数のインスタンスを使用して、許可リストの複数の証明書を指定できます。
次の手順では、TRUST_CONFIG_NAME を TrustConfig リソースの名前に置き換えます。
トラストストアを含む
trust_config.yamlファイルを作成するには、次のコマンドを使用します。cat << EOF > trust_config.yaml trustStores: - trustAnchors: - pemCertificate: "${ROOT_CERT?}" - pemCertificate: "${ROOT_CERT_2?}" intermediateCas: - pemCertificate: "${INTERMEDIATE_CERT?}" - pemCertificate: "${INTERMEDIATE_CERT_2?}" EOF省略可: 許可リストに追加した証明書を含む
trust_config.yamlファイルを作成するには、次のコマンドを使用します。cat << EOF > trust_config.yaml allowlistedCertificates: - pemCertificate: "${ALLOWLISTED_CERT?}" EOFCertificate Manager の
TrustConfigリソースを作成するには、gcloud certificate-manager trust-configs importコマンドを使用します。グローバル
外部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --source=trust_config.yaml
リージョン
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
gcloud certificate-manager trust-configs import TRUST_CONFIG_NAME \ --source=trust_config.yaml \ --location=REGION
クライアント認証リソースを作成する
クライアント認証（ServerTLSPolicy とも呼ばれます）リソースを使用すると、クライアント証明書の検証で使用するサーバーサイド TLS モードと TrustConfig リソースを指定できます。クライアントがロードバランサに無効な証明書を提示するか、証明書を提示しない場合は、clientValidationMode でクライアント接続の処理方法を指定します。詳細については、MTLS クライアント検証モードをご覧ください。
clientValidationModeがALLOW_INVALID_OR_MISSING_CLIENT_CERTに設定されている場合、検証が失敗した場合やクライアント証明書が欠落していても、すべてのリクエストがバックエンドに渡されます。clientValidationModeがREJECT_INVALIDに設定されている場合、TrustConfigリソースの検証が可能なクライアント証明書を提示するリクエストのみがバックエンドに渡されます。
ServerTLSPolicy リソースを作成するには、次の手順を完了します。
接続の処理方法に応じて、次のいずれかのオプションを選択します。
次の手順では、
SERVER_TLS_POLICY_NAMEをサーバー TLS ポリシーの名前に置き換え、PROJECT_IDを Google Cloud プロジェクトの ID に置き換えます。オプション 1:
clientValidationModeがALLOW_INVALID_OR_MISSING_CLIENT_CERTに設定されている。server_tls_policy.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
リージョン
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
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に設定されている。server_tls_policy.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
リージョン
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
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
ServerTlsPolicyリソースを作成するには、gcloud network-security server-tls-policies importコマンドを使用します。グローバル
外部アプリケーション ロードバランサとクロスリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \ --source=server_tls_policy.yaml \ --location=global
リージョン
リージョン外部アプリケーション ロードバランサとリージョン内部アプリケーション ロードバランサの場合は、次のコマンドを使用します。
gcloud network-security server-tls-policies import SERVER_TLS_POLICY_NAME \ --source=server_tls_policy.yaml \ --location=REGION
省略可: 現在のプロジェクトのロケーションにあるすべてのクライアント認証（
ServerTlsPolicies）リソースを一覧表示します。コンソール
Google Cloud コンソールで、[クライアント認証] ページに移動します。
すべての
ServerTlsPoliciesリソースが表示されます。
gcloud
すべてのクライアント認証（
ServerTlsPolicies）リソースを一覧表示するには、gcloud network-security server-tls-policies listコマンドを使用します。gcloud network-security server-tls-policies list \ --location=REGION
次のように置き換えます。
REGION: クロスリージョン内部アプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、または従来のアプリケーション ロードバランサには、globalを使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。
ロードバランサに mTLS を設定する
相互 TLS 認証を機能させるには、ロードバランサを設定した後、ServerTLSPolicy リソースを使用してターゲット HTTPS プロキシを更新する必要があります。
クライアント認証（
ServerTLSPolicy）リソースが作成されていることを確認します。手順については、クライアント認証リソースを作成するをご覧ください。プロジェクト内のすべてのターゲット HTTPS プロキシを一覧表示するには、
gcloud compute target-https-proxies listコマンドを使用します。gcloud compute target-https-proxies list
ServerTLSPolicyリソースを接続するターゲット HTTPS プロキシの名前をメモします。以降のステップでは、この名前をTARGET_HTTPS_PROXY_NAMEとして表しています。ターゲット 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.yamlREGION: ロードバランサを構成したリージョン。
現在のプロジェクトの指定されたロケーションにある
ServerTlsPoliciesリソースを一覧表示します。コンソール
Google Cloud コンソールで、[クライアント認証] ページに移動します。
すべての
ServerTlsPoliciesリソースが表示されます。
gcloud
すべてのクライアント認証（
ServerTlsPolicies）リソースを一覧表示するには、gcloud network-security server-tls-policies listコマンドを使用します。gcloud network-security server-tls-policies list \ --location=REGION
次のように置き換えます。
REGION: クロスリージョン内部アプリケーション ロードバランサ、グローバル外部アプリケーション ロードバランサ、または従来のアプリケーション ロードバランサには、globalを使用します。リージョン外部アプリケーション ロードバランサまたはリージョン内部アプリケーション ロードバランサには、ロードバランサを構成したリージョンを使用します。mTLS を構成する
ServerTlsPoliciesリソースの名前をメモします。この名前は、次のステップでSERVER_TLS_POLICY_NAMEとして参照しています。ServerTlsPolicyリソース ファイルTARGET_PROXY_FILENAMEを追加するには、次のコマンドを使用します。PROJECT_IDは、Google Cloud プロジェクトの ID に置き換えます。echo "serverTlsPolicy: //networksecurity.googleapis.com/projects/PROJECT_ID/locations/REGION/serverTlsPolicies/SERVER_TLS_POLICY_NAME" >> TARGET_PROXY_FILENAME
ターゲット 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.yamlREGION: ロードバランサを構成したリージョン。
mTLS カスタム ヘッダーを追加する
mTLS を有効にすると、カスタム ヘッダーを使用して mTLS 接続に関する情報を渡すことができます。また、ロギングを有効にして、mTLS 接続エラーをログにキャプチャすることもできます。
バックエンド サービスに mTLS カスタム ヘッダーを追加する
グローバル外部アプリケーション ロードバランサまたは従来のアプリケーション ロードバランサの場合、カスタム ヘッダーを使用して mTLS 接続に関する情報をバックエンド サービスに渡すことができます。
プロジェクト内のすべてのバックエンド サービスを一覧表示するには、
gcloud compute backend-services listコマンドを使用します。gcloud compute backend-services list
カスタム ヘッダーとロギングを有効にするため、バックエンド サービスの名前をメモします。この名前は、次のステップで
BACKEND_SERVICEとして参照されます。バックエンド サービスを更新するには、
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 リソースを作成している場合は、次の操作を行います。
クライアント キー構成ファイルを作成します。
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 EOFSPIFFE ID が関連付けられている場合:
次のように
subjectAltNameを[extension_requirements]セクションに追加します。subjectAltName = @sans_list
client.configファイルの下部に、次の内容の新しいセクションを追加します。[sans_list] URI.1 = spiffe://example.com/test-identity
鍵に署名します。
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テストするために、ロードバランサの IP アドレスに
curlリクエストを送信します。curl -v -k --key client.key --cert client.cert https://IP_ADDRESS
IP_ADDRESS は、ロードバランサの IP アドレスに置き換えます。