Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Mengonfigurasi konektivitas Certificate Authority melalui proxy
Panduan ini menjelaskan cara mengonfigurasi konektivitas certificate authority (CA)
melalui proxy saat konektivitas langsung dari beban kerja yang dimasukkan sidecar
tidak tersedia (misalnya, karena firewall atau fitur pembatasan lainnya).
Konfigurasi ini hanya berlaku untuk penginstalan Cloud Service Mesh yang menggunakan
Layanan Otoritas Sertifikasi.
Dalam penginstalan Cloud Service Mesh dalam cluster biasa, Anda men-deploy sidecar di
pod aplikasi tempat konektivitas langsung ke layanan CA (seperti
meshca.googleapis.com dan privateca.googleapis.com) tersedia. Dalam
skenario saat koneksi langsung tidak tersedia, Anda harus mengonfigurasi
proxy HTTPS berbasis CONNECT eksplisit.
Prasyarat
Sebelum mengonfigurasi konektivitas CA melalui proxy, pastikan Anda memiliki:
Membangun konektivitas jaringan dari semua pod yang dimasukkan sidecar ke proxy
HTTPS.
Memberikan akses untuk proxy HTTPS yang di-deploy ke semua layanan Google Cloud .
CA_PLUGIN_PROXY_URL adalah konfigurasi yang digunakan oleh sidecar untuk membuat
handshake CONNECT dengan proxy yang kemudian meneruskan semua traffic yang ditujukan ke
CA ke endpoint yang relevan.
proxy-service di-deploy di namespace proxy-ns dan memproses handshake CONNECT di port proxy-port. Format variabel lingkungan ini mirip dengan variabel lingkungan HTTPS_PROXY standar.
Setelah platform kontrol Cloud Service Mesh diinstal, terapkan
CR ProxyConfig yang sesuai (dikonfigurasi di langkah 1) di cluster sebelum
memulai ulang beban kerja di namespace berlabel Cloud Service Mesh untuk memastikan bahwa
konfigurasi dimasukkan dengan benar ke sidecar. Konfigurasi ini
diperlukan agar sidecar mendapatkan sertifikat workload yang ditandatangani dari CA, yang
memastikan bahwa pod yang dimasukkan sidecar dapat dimulai.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-08-18 UTC."],[],[],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."]]
