Ret Envoys upstream TLS-kontekst mod dens CA-bundt i containeren

For TLS, der startes af et dynamisk forward-proxy-klynge, skal du konfigurere trusted_ca på den klynge og bevare SAN-verifikationen af destinationen.

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

Flet dette sammen med konfigurationen af det dynamiske forward-proxy-klynge. Den godkendte bundtsti skal kunne læses af Envoy-processen, der kører. I Kubernetes skal du undersøge den monterede fil inde i containeren; et certifikat, der kun er installeret på arbejdsnoden, leverer det ikke.

Medtag den krævede CA via deploymentets proces for tillidsmateriale, og bekræft, at destinationen leverer de nødvendige mellemliggende certifikater. Anvend ændringer via den valgte konfigurations- eller hemmelighedsopdateringsmekanisme.

Den dokumenterede dynamiske forward-proxy-TLS-opsætning leverer SNI- og værtsnavn-SAN-verifikation for den opløste vært. Behold den identitetskontrol sammen med kædevalidering.

En vellykket wget-anmodning kan bruge en anden tillidskilde. Dette input dækker TLS, der stammer fra Envoy; i et almindeligt CONNECT-relæ forbliver applikationen TLS-klienten, der validerer destinationen.

Relaterede artikler