Pek Envoys upstream-TLS-kontekst mot CA-pakken i containeren

For TLS som startes av et dynamisk forward-proxy-klynge, konfigurer trusted_ca på den klyngen mens SAN-verifiseringen av målet beholdes.

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

Slå dette sammen med konfigurasjonen av det dynamiske forward-proxy-klyngen. Banen til den godkjente pakken må være lesbar for Envoy-prosessen som kjører. I Kubernetes, undersøk den monterte filen inne i containeren; et sertifikat som bare er installert på arbeidsnoden gir det ikke.

Ta med den nødvendige CA-en gjennom distribusjonens prosess for tillitsmateriale, og bekreft at målet leverer de nødvendige mellomliggende sertifikatene. Bruk endringer gjennom den valgte konfigurasjons- eller hemmelighetsoppdateringsmekanismen.

Det dokumenterte dynamiske forward-proxy-TLS-oppsettet gir SNI- og vertsnavn-SAN-verifisering for den oppløste verten. Behold den identitetskontrollen sammen med validering av kjeden.

En vellykket wget-forespørsel kan bruke en annen tillitskilde. Denne inngangen dekker TLS som stammer fra Envoy; i et vanlig CONNECT-relé forblir applikasjonen TLS-klienten som validerer målet.

Relaterte artikler