Configure Certificate Authority connectivity through a proxy

This guide explains how to configure certificate authority (CA) connectivity through a proxy when direct connectivity from the sidecar-injected workloads is not available (for example, due to firewalls or other restrictive features). This configuration is only applicable for Cloud Service Mesh installations that use Certificate Authority Service.

In a typical in-cluster Cloud Service Mesh installation, you deploy sidecars in application pods where direct connectivity to CA services (such as meshca.googleapis.com and privateca.googleapis.com) is available. In scenarios where a direct connection is not available, you must configure an explicit CONNECT-based HTTPS proxy.

Prerequisites

Before configuring CA connectivity through a proxy, ensure you have:

Established network connectivity from all sidecar injected pods to the HTTPS proxy.
Granted access for the deployed HTTPS proxy to all Google Cloud services.

Configure a ProxyConfig custom resource

Configure an Istio ProxyConfig custom resource (CR) to inject into the sidecar proxy to point to the HTTPS proxy. For example:
```
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>
```
where:
- 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.
- 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.
Once the Cloud Service Mesh control plane has been installed, apply the appropriate ProxyConfig CR (configured in step 1) on the cluster before restarting workloads in Cloud Service Mesh-labeled namespaces to ensure that the configuration is correctly injected into the sidecars. This configuration is required for sidecars to get signed workload certificates from the CA, which ensures that the sidecar injected pod can start up.