Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
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 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 sidecars em
pods de aplicativo em que a conectividade direta com os serviços de CA (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 Google Cloud serviços.
Configurar um recurso personalizado de ProxyConfig
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.
Depois que o plano de controle do Cloud Service Mesh for instalado, aplique o
CR ProxyConfig apropriado (configurado na etapa 1) no cluster antes
de reiniciar as cargas de trabalho em namespaces rotulados pelo Cloud Service Mesh para garantir que a
configuração seja injetada corretamente nos sidecars. 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.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["Configure Certificate Authority connectivity through a proxy\n\nThis guide explains how to configure certificate authority (CA) connectivity\nthrough a proxy when direct connectivity from the sidecar-injected workloads is\nnot available (for example, due to firewalls or other restrictive features).\nThis configuration is only applicable for Cloud Service Mesh installations that use\n[Certificate Authority Service](../install-anthos-service-mesh#install_ca_service).\n| **Warning:** This guide only ensures CA connectivity through a proxy. However, note that Telemetry and Observability features (including metrics explorer, Cloud Service Mesh UI) **do not work** when workloads are behind a proxy.\n\nIn a typical in-cluster Cloud Service Mesh installation, you deploy sidecars in\napplication pods where direct connectivity to CA services (such as\n`meshca.googleapis.com` and `privateca.googleapis.com`) is available. In\nscenarios where a direct connection is not available, you must configure an\nexplicit `CONNECT`-based HTTPS proxy.\n\nPrerequisites\n\nBefore configuring CA connectivity through a proxy, ensure you have:\n\n- Established network connectivity from all sidecar injected pods to the HTTPS proxy.\n- Granted access for the deployed HTTPS proxy to all Google Cloud services.\n\nConfigure a ProxyConfig custom resource\n\n1. Configure an\n [Istio ProxyConfig custom resource (CR)](https://istio.io/latest/docs/reference/config/networking/proxy-config/)\n to inject into the sidecar proxy to point to the HTTPS proxy. For example:\n\n apiVersion: networking.istio.io/v1beta1\n kind: ProxyConfig\n metadata:\n labels:\n istio.io/rev: \u003cistio-rev\u003e # To target proxies mapped to a specific control plane if needed.\n name: test-proxy-inject\n namespace: istio-system # To ensure side-cars injected into all namespaces process this CR\n spec:\n environmentVariables:\n CA_PLUGIN_PROXY_URL: http://\u003cproxy-service\u003e.\u003cproxy-ns\u003e:\u003cproxy-port\u003e\n\n where:\n - `CA_PLUGIN_PROXY_URL` is the configuration consumed by sidecars to establish a `CONNECT` handshake with the proxy which then forwards all CA-destined traffic to the relevant endpoint.\n - `proxy-service` is deployed in the `proxy-ns` namespace and listening for `CONNECT` handshakes on `proxy-port` port. The format of this environment variable is similar to the standard `HTTPS_PROXY` environment variable.\n2. Once the Cloud Service Mesh control plane has been installed, apply the\n appropriate `ProxyConfig` CR (configured in step 1) on the cluster **before**\n restarting workloads in Cloud Service Mesh-labeled namespaces to ensure that the\n configuration is correctly injected into the sidecars. This configuration is\n required for sidecars to get signed workload certificates from the CA, which\n ensures that the sidecar injected pod can start up."]]
