Envoy の上流 TLS コンテキストをコンテナ内の CA バンドルに向ける

動的フォワードプロキシクラスタが開始する TLS では、そのクラスタに trusted_ca を設定し、宛先の SAN 検証を維持します。

transport_socket:
  name: envoy.transport_sockets.tls
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
    common_tls_context:
      validation_context:
        trusted_ca:
          filename: /etc/envoy/trust/upstream-ca.pem

これを動的フォワードプロキシクラスタの構成と統合します。承認済みバンドルのパスは、実行中の Envoy プロセスから読み取れる必要があります。Kubernetes では、コンテナ内にマウントされたファイルを確認します。ワーカーノードにのみインストールされた証明書では、それは提供されません。

必要な CA をデプロイのトラストマテリアル手順で含め、宛先が必要な中間証明書を提供することを確認します。変更は、選択した構成またはシークレット更新の仕組みを通じて適用します。

文書化された動的フォワードプロキシ TLS の設定は、解決されたホストに対して SNI とホスト名 SAN の検証を提供します。この ID チェックをチェーン検証と併せて維持してください。

成功した wget リクエストは別の信頼ソースを使用できます。この入力は Envoy が発信する TLS を対象としています。単純な CONNECT リレーでは、アプリケーションが宛先を検証する TLS クライアントのままです。

関連記事