Configure Certificate Authority connectivity through a proxy
This page 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 Anthos Service Mesh installations that use Certificate Authority Service.
In a typical in-cluster Anthos Service Mesh installation, you deploy sidecars in
application pods where direct connectivity to CA services (such as
privateca.googleapis.com) is available. In
scenarios where a direct connection is not available, you must configure an
CONNECT-based HTTPS proxy.
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>
CA_PLUGIN_PROXY_URLis the configuration consumed by sidecars to establish a
CONNECThandshake with the proxy which then forwards all CA-destined traffic to the relevant endpoint.
proxy-serviceis deployed in the
proxy-nsnamespace and listening for
proxy-portport. The format of this environment variable is similar to the standard
Once the Anthos Service Mesh control plane has been installed, apply the appropriate
ProxyConfigCR (configured in step 1) on the cluster before restarting workloads in Anthos 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.