Спрямуйте контекст 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-клієнтом, який перевіряє призначення.

Схожі статті