Насочете upstream TLS контекста на Envoy към CA пакета в контейнера

За TLS, иницииран от динамичен forward-proxy клъстер, конфигурирайте trusted_ca на този клъстер, като запазите проверката на SAN за дестинацията.

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

Обединете това с конфигурацията на динамичния forward-proxy клъстер. Одобреният път до пакета трябва да е достъпен за четене от работещия процес на Envoy. В Kubernetes проверете монтирания файл вътре в контейнера; сертификат, инсталиран само на работния възел, не го осигурява.

Включете необходимия CA чрез процеса за доверителни материали на разгръщането и потвърдете, че дестинацията предоставя нужните междинни сертификати. Прилагайте промените чрез избрания механизъм за конфигурация или обновяване на тайни.

Документираната настройка за динамичен forward-proxy TLS осигурява SNI и проверка на SAN за името на хоста за разрешения хост. Запазете тази проверка на идентичността заедно с валидирането на веригата.

Успешна заявка wget може да използва друг източник на доверие. Този вход обхваща TLS, произхождащ от Envoy; при обикновен CONNECT релей приложението остава TLS клиентът, който валидира дестинацията.

Подобни статии