Накіраваць кантэкст upstream TLS у Envoy на CA-пакет унутры кантэйнера

Для TLS, які запускае дынамічны кластар forward-proxy, наладзьце 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

Аб'яднайце гэта з канфігурацыяй дынамічнага кластара forward-proxy. Шлях да зацверджанага пакета павінен быць чытэльным для працэсу Envoy, які выконваецца. У Kubernetes праверце змантаваны файл унутры кантэйнера; сертыфікат, усталяваны толькі на працоўным вузле, не забяспечвае гэтага.

Уключыце патрэбны CA праз працэс даверных матэрыялаў разгортвання і пераканайцеся, што прызначэнне падае патрэбныя прамежкавыя сертыфікаты. Ужывайце змены праз абраны механізм канфігурацыі або абнаўлення сакрэтаў.

Задакументаваная налада дынамічнага forward-proxy TLS забяспечвае праверку SNI і SAN імені хоста для вырашанага хоста. Захоўвайце гэтую праверку ідэнтычнасці разам з праверкай ланцуга.

Паспяховы запыт wget можа выкарыстоўваць іншую крыніцу даверу. Гэтыя ўводзіны ахопліваюць TLS, які паходзіць ад Envoy; у звычайным рэлеі CONNECT праграма застаецца TLS-кліентам, які правярае прызначэнне.

Падобныя артыкулы