Rjochtsje Envoy syn upstream TLS-kontekst op syn CA-bondel yn 'e container

Foar TLS dat troch in dynamysk forward-proxy-kluster begûn wurdt, konfigurearje trusted_ca op dat kluster en behâld de SAN-ferifikaasje fan 'e bestimming.

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

Foegje dit gear mei de konfiguraasje fan it dynamyske forward-proxy-kluster. It paad fan 'e goedkarde bondel moat lêsber wêze foar it rinnende Envoy-proses. Yn Kubernetes, besjoch it mounte bestân yn 'e container; in sertifikaat dat allinnich op 'e worker-node ynstallearre is, leveret it net.

Foegje de fereaske CA ta fia it trust-materiaalproses fan 'e útrôl en befêstigje dat de bestimming de nedige tuskenlizzende sertifikaten leveret. Pas feroarings ta fia it keazen konfiguraasje- of geheimen-bywurkingsmeganisme.

De dokumintearre dynamyske forward-proxy-TLS-opsis leveret SNI- en hostnamme-SAN-ferifikaasje foar de oploste host. Hâld dy identiteitskontrôle njonken ketenferifikaasje.

In suksesfol wget-fersyk kin in oare fertrouwensboarne brûke. Dizze ynfier beslacht TLS dat fan Envoy ôfkomstich is; yn in gewoane CONNECT-relay bliuwt de applikaasje de TLS-klant dy't de bestimming ferifiearret.

Relatearre artikelen