安装 Cloud Service Mesh 控制平面后,先在集群上应用适当的 ProxyConfig CR(在第 1 步中配置),然后在 Cloud Service Mesh 标记的命名空间中重启工作负载,以确保配置正确注入到边车中。边车需要此配置才能从 CA 获取签名工作负载证书,这可确保边车注入的 pod 可以启动。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-18。"],[],[],null,["# Configure Certificate Authority connectivity through a proxy\n============================================================\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-------------\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---------------------------------------\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."]]