Apunta el contexto TLS ascendente de Envoy a su paquete de CA dentro del contenedor

Para el TLS originado por un clúster de proxy directo dinámico, configure trusted_ca en ese clúster manteniendo la verificación SAN del destino.

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

Combine esto con la configuración del clúster de proxy directo dinámico. La ruta del paquete aprobado debe ser legible por el proceso de Envoy en ejecución. En Kubernetes, inspeccione el archivo montado dentro del contenedor; un certificado instalado solo en el nodo trabajador no lo proporciona.

Incluya la CA requerida mediante el proceso de material de confianza del despliegue y confirme que el destino proporciona los certificados intermedios necesarios. Aplique los cambios mediante el mecanismo de configuración o de actualización de secretos elegido.

La configuración documentada de TLS de proxy directo dinámico proporciona SNI y verificación SAN del nombre de host para el host resuelto. Mantenga esa comprobación de identidad junto con la validación de la cadena.

Una solicitud wget correcta puede usar otra fuente de confianza. Esta entrada abarca el TLS originado por Envoy; en un relé CONNECT simple, la aplicación sigue siendo el cliente TLS que valida el destino.

Artículos relacionados