Configurar la conectividad de la autoridad de certificación a través de un proxy

En esta guía se explica cómo configurar la conectividad de la autoridad de certificación (CA) a través de un proxy cuando no se dispone de conectividad directa desde las cargas de trabajo insertadas en el sidecar (por ejemplo, debido a cortafuegos u otras funciones restrictivas). Esta configuración solo se aplica a las instalaciones de Cloud Service Mesh que usan el Servicio de Autoridades de Certificación.

En una instalación típica de Cloud Service Mesh en un clúster, se implementan sidecars en pods de aplicaciones en los que se dispone de conectividad directa a servicios de CA (como meshca.googleapis.com y privateca.googleapis.com). En los casos en los que no haya una conexión directa, debes configurar un proxy HTTPS explícito basado en CONNECT.

Requisitos previos

Antes de configurar la conectividad de la AC a través de un proxy, asegúrate de que tienes lo siguiente:

  • Conectividad de red establecida desde todos los pods con sidecar insertado al proxy HTTPS.
  • Se ha concedido acceso al proxy HTTPS implementado a todos los servicios de Google Cloud .

Configurar un recurso personalizado ProxyConfig

  1. Configura un recurso personalizado (CR) ProxyConfig de Istio para insertarlo en el proxy sidecar y que apunte al proxy HTTPS. Por ejemplo:

    apiVersion: networking.istio.io/v1beta1
    kind: ProxyConfig
    metadata:
     labels:
      istio.io/rev: <istio-rev>   # To target proxies mapped to a specific control plane if needed.
     name: test-proxy-inject
     namespace: istio-system      # To ensure side-cars injected into all namespaces process this CR
    spec:
     environmentVariables:
      CA_PLUGIN_PROXY_URL: http://<proxy-service>.<proxy-ns>:<proxy-port>
    

    donde:

    • CA_PLUGIN_PROXY_URL es la configuración que usan los sidecars para establecer un handshake CONNECT con el proxy, que luego reenvía todo el tráfico destinado a la CA al endpoint correspondiente.
    • proxy-service se implementa en el espacio de nombres proxy-ns y escucha handshakes CONNECT en el puerto proxy-port. El formato de esta variable de entorno es similar al de la variable de entorno HTTPS_PROXY estándar.
  2. Una vez que se haya instalado el plano de control de Cloud Service Mesh, aplica el CR ProxyConfig adecuado (configurado en el paso 1) en el clúster antes de reiniciar las cargas de trabajo en los espacios de nombres etiquetados con Cloud Service Mesh para asegurarte de que la configuración se inserta correctamente en los sidecars. Esta configuración es necesaria para que los sidecars obtengan certificados de carga de trabajo firmados de la AC, lo que asegura que el pod insertado del sidecar pueda iniciarse.