Configurar a conectividade da autoridade certificadora por um proxy
do tipoNeste 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 é aplicável apenas a instalações do Cloud Service Mesh que usam o Certificate Authority Service.
Em uma instalação típica do Cloud Service Mesh no cluster, você implanta arquivos secundários em
pods de aplicativos em que a conectividade direta com serviços de AC (como
meshca.googleapis.com
e privateca.googleapis.com
) está disponível. 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
Configure um recurso personalizado (CR, na sigla em inglês) ProxyConfig do Istio para injetar no proxy secundário de modo que ele aponte 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 deCONNECT
com o proxy, que encaminha todo o tráfego destinado a CA para o endpoint relevante.proxy-service
é implantado no namespaceproxy-ns
e ouve handshakes deCONNECT
na portaproxy-port
. O formato dessa variável de ambiente é semelhante ao da variável de ambienteHTTPS_PROXY
padrão.
Depois que o plano de controle do Cloud Service Mesh tiver sido instalado, aplique a resposta automática
ProxyConfig
apropriada (configurada na etapa 1) no cluster antes de reiniciar as cargas de trabalho nos namespaces rotulados pelo Cloud Service Mesh para garantir que a configuração seja 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.