Direktu la supran TLS-kuntekston de Envoy al sia CA-pakaĵo ene de la ujo

Por TLS iniciatita de dinamika antaŭa-prokura klastro, agordu trusted_ca sur tiu klastro konservante la SAN-kontrolon de la celo.

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

Kunfandu ĉi tion kun la agordo de la dinamika antaŭa-prokura klastro. La vojo de la aprobita pakaĵo devas esti legebla de la funkcianta Envoy-procezo. En Kubernetes, kontrolu la muntitan dosieron ene de la ujo; atestilo instalita nur sur la labora nodo ne provizas ĝin.

Inkluzivu la bezonatan CA per la fid-materiala procezo de la deplojo, kaj konfirmu ke la celo provizas la necesajn mezajn atestilojn. Apliku ŝanĝojn per la elektita agorda aŭ sekretaĵ-ĝisdatiga mekanismo.

La dokumentita dinamika antaŭa-prokura TLS-agordo provizas SNI kaj gastigantnoma SAN-kontrolon por la solvita gastiganto. Konservu tiun identec-kontrolon apud la ĉena validigo.

Sukcesa wget-peto povas uzi alian fidfonton. Ĉi tiu enigo kovras TLS originantan de Envoy; en ordinara CONNECT-relajo, la aplikaĵo restas la TLS-kliento validiganta la celon.

Rilataj artikoloj