Ituro ang upstream TLS context ng Envoy sa CA bundle sa loob ng container

Para sa TLS na sinisimulan ng isang dynamic na forward-proxy cluster, i-configure ang trusted_ca sa cluster na iyon habang pinapanatili ang SAN verification ng destinasyon.

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

Pagsamahin ito sa configuration ng dynamic na forward-proxy cluster. Dapat mabasa ng tumatakbong proseso ng Envoy ang path ng aprubadong bundle. Sa Kubernetes, siyasatin ang naka-mount na file sa loob ng container; hindi ito ibinibigay ng certificate na naka-install lamang sa worker node.

Isama ang kinakailangang CA sa pamamagitan ng trust-material na proseso ng deployment, at kumpirmahin na ibinibigay ng destinasyon ang mga kinakailangang intermediate certificate. Ilapat ang mga pagbabago sa pamamagitan ng napiling configuration o secret-update na mekanismo.

Ang dokumentadong dynamic na forward-proxy TLS setup ay nagbibigay ng SNI at hostname SAN verification para sa naresolba na host. Panatilihin ang identity check na iyon kasama ng chain validation.

Ang matagumpay na wget request ay maaaring gumamit ng ibang trust source. Sinasaklaw ng input na ito ang TLS na nagmumula sa Envoy; sa isang plain CONNECT relay, ang application ay nananatiling TLS client na nagva-validate ng destinasyon.

Kaugnay na mga artikulo