Pek Envoy sin upstream-TLS-kontekst mot CA-pakken i containeren

For TLS som blir starta av ein dynamisk forward-proxy-klynge, konfigurer trusted_ca på den klynga medan SAN-verifiseringa av målet blir halden.

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 saman med konfigurasjonen av den dynamiske forward-proxy-klynga. Stien til den godkjende pakken må vere lesbar for Envoy-prosessen som køyrer. I Kubernetes, undersøk den monterte fila inne i containeren; eit sertifikat som berre er installert på arbeidsnoden gjev det ikkje.

Ta med den nødvendige CA-en gjennom distribusjonen sin prosess for tillitsmateriale, og stadfest at målet leverer dei nødvendige mellomliggjande sertifikata. Bruk endringar gjennom den valde konfigurasjons- eller løyndomsoppdateringsmekanismen.

Det dokumenterte dynamiske forward-proxy-TLS-oppsettet gjev SNI- og vertsnamn-SAN-verifisering for den oppløyste verten. Hald den identitetskontrollen saman med validering av kjeda.

Ein vellukka wget-førespurnad kan bruke ei anna tillitskjelde. Denne inngangen dekkjer TLS som kjem frå Envoy; i eit vanleg CONNECT-relé blir applikasjonen verande TLS-klienten som validerer målet.

Relaterte artiklar