Pointez le contexte TLS amont d'Envoy vers son bundle CA dans le conteneur

Pour le TLS initié par un cluster de proxy direct dynamique, configurez trusted_ca sur ce cluster tout en conservant la vérification SAN de la destination.

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

Fusionnez ceci avec la configuration du cluster de proxy direct dynamique. Le chemin du bundle approuvé doit être lisible par le processus Envoy en cours d'exécution. Dans Kubernetes, inspectez le fichier monté à l'intérieur du conteneur ; un certificat installé uniquement sur le nœud worker ne le fournit pas.

Incluez l'autorité de certification requise via le processus de matériel de confiance du déploiement, et confirmez que la destination fournit les intermédiaires nécessaires. Appliquez les changements via le mécanisme de configuration ou de mise à jour des secrets choisi.

La configuration TLS documentée pour le proxy direct dynamique fournit la vérification SNI et SAN du nom d'hôte pour l'hôte résolu. Conservez ce contrôle d'identité aux côtés de la validation de chaîne.

Une requête wget réussie peut utiliser une autre source de confiance. Cette entrée couvre le TLS émis par Envoy ; dans un relais CONNECT simple, l'application reste le client TLS qui valide la destination.

Articles similaires