Configurar a conectividade da autoridade certificadora por um proxy

Neste guia, explicamos como configurar a conectividade da autoridade certificadora (CA) por meio de um proxy quando a conectividade direta das cargas de trabalho injetadas por sidecar não está disponível (por exemplo, devido a firewalls ou outros recursos restritivos). Essa configuração só é aplicável às instalações do Cloud Service Mesh que usam Certificate Authority Service:

Em uma instalação típica do Cloud Service Mesh no cluster, você implanta arquivos secundários pods de aplicativos em que a conectividade direta com serviços de CA (como meshca.googleapis.com e privateca.googleapis.com). Em cenários em que uma conexão direta não está disponível, é necessário configurar um proxy HTTPS explícito baseado em CONNECT.

Pré-requisitos

Antes de configurar a conectividade da CA por um proxy, confirme se você:

  • Estabeleceu a conectividade de rede de todos os pods injetados por sidecar com o proxy HTTPS.
  • Concedeu acesso ao proxy HTTPS implantado para todos os serviços do Google Cloud.

Configurar um recurso personalizado de ProxyConfig

  1. Configure um Recurso personalizado ProxyConfig (CR) do Istio a ser injetada no proxy sidecar para apontar para o proxy HTTPS. Exemplo:

    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>
    

    onde:

    • CA_PLUGIN_PROXY_URL é a configuração consumida pelos sidecars para estabelecer um handshake de CONNECT com o proxy, que encaminha todo o tráfego destinado a CA para o endpoint relevante.
    • proxy-service é implantado no namespace proxy-ns e ouve handshakes de CONNECT na porta proxy-port. O formato dessa variável de ambiente é semelhante ao da variável de ambiente HTTPS_PROXY padrão.
  2. Depois que o plano de controle do Cloud Service Mesh for instalado, aplique o Resposta automática ProxyConfig adequada (configurada na etapa 1) no cluster antes reiniciar cargas de trabalho em namespaces rotulados no Cloud Service Mesh para garantir que é injetada corretamente nos arquivos secundários. Essa configuração é necessária para que os sidecars recebam certificados de carga de trabalho assinados da CA, o que garante que o pod injetado do sidecar seja iniciado.