0

インターネットと VPC 内の他のサービスの両方からのリクエストを処理するためのサービスを GCE にセットアップしました。

これを管理するために、2 つのロード バランサーを並行してセットアップしました。1 つ目はグローバル HTTPS ロード バランサーで、2 つ目は内部 HTTPS ロード バランサーです。両方のロード バランサーには、サービスをホストしている同じインスタンス グループにトラフィックを送信するように構成されたバックエンド サービスがあります。

グローバル ロード バランサーについては、ドメイン用に自己管理型の証明書を作成し、これらの証明書を定期的に更新するために小さな VM をセットアップしました。

内部ロード バランサーの証明書を構成する方法に行き詰まっています。私たちの調査によると、最良のオプションは、自己署名証明書を作成し、LB と通信する各 VM にそれらをインストール/信頼することに帰着するようです。ただし、これの管理 (または同様に独自のローカル CA の管理) にはコストがかかるようです。GCP は、内部デプロイ用の証明書を管理するのに役立ちますか? 自己署名証明書ルートに行き詰まっていますか? または、検討すべき別のアプローチはありますか?

ありがとうございます。

4

1 に答える 1

2

グローバル ロード バランサーについては、ドメイン用に自己管理型の証明書を作成し、これらの証明書を定期的に更新するために小さな VM をセットアップしました。

Google クラウド マネージド SSL 証明書を使用すると、証明書を更新するための余分な VM を回避できます。ただし、関連する可能性のある特定の制限があります。

  • ドメイン検証 (DV) 証明書のみ
  • 証明書ごとに単一のドメイン名
  • ワイルドカードの共通名または複数のサブジェクト代替名はサポートされていません

内部ロード バランサーの証明書を構成する方法に行き詰まっています。この内部証明書はどのドメインに対して構成する必要がありますか?

グローバル HTTPS ロード バランサの場合、LB とバックエンド インスタンス間のトラフィックはデフォルトで暗号化されるため、個々の VM インスタンスに SSL 証明書は必要ありません。

VM 間の内部トラフィックを暗号化する場合 (そして、この追加の保護レイヤーが本当に必要な場合) は、自己署名証明書を使用し、それをリージョンの HTTP プロキシ構成で指定する必要があります。

内部ロード バランサーが使用する DNS 形式は次のとおりです。

[SERVICE_LABEL].[FORWARDING_RULE_NAME].il4.[REGION].lb.[PROJECT_ID].internal

さまざまな内部サービスに一致するように、自己署名のワイルド カード証明書を作成できます。独自の認証局を保持することにはいくつかの欠点があります。詳細については、https://security.stackexchange.com/a/121195/52705を参照してください。

ドキュメンテーション：

于 2019-09-12T08:22:47.777 に答える