Skieruj kontekst TLS nadrzędnego Envoy na pakiet CA w kontenerze

Dla TLS inicjowanego przez dynamiczny klaster forward-proxy skonfiguruj trusted_ca na tym klastrze, zachowując weryfikację SAN celu.

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

Połącz to z konfiguracją dynamicznego klastra forward-proxy. Ścieżka zatwierdzonego pakietu musi być czytelna dla działającego procesu Envoy. W Kubernetes sprawdź zamontowany plik wewnątrz kontenera; certyfikat zainstalowany tylko na węźle roboczym tego nie zapewnia.

Uwzględnij wymagany CA poprzez proces materiałów zaufania wdrożenia i potwierdź, że cel dostarcza potrzebne certyfikaty pośrednie. Zastosuj zmiany przez wybrany mechanizm konfiguracji lub aktualizacji sekretów.

Udokumentowana konfiguracja TLS dynamicznego forward-proxy zapewnia weryfikację SNI i SAN nazwy hosta dla rozwiązanego hosta. Zachowaj tę kontrolę tożsamości obok walidacji łańcucha.

Udane żądanie wget może korzystać z innego źródła zaufania. To wejście obejmuje TLS pochodzący z Envoy; w zwykłym przekaźniku CONNECT aplikacja pozostaje klientem TLS walidującym cel.

Powiązane artykuły