為確保在正式環境和開發環境中，與 AlloyDB for PostgreSQL 執行個體保持安全可靠的連線，請在部署及管理 AlloyDB Auth Proxy 時，遵循下列最佳做法。
將驗證 Proxy 用戶端保持在最新狀態
Google 每月都會發布新版 Auth Proxy。如要查看目前版本，請前往 AlloyDB Auth Proxy GitHub 版本頁面。
使用自動化功能更新 Auth Proxy 版本，並在非正式環境中測試新版本，再將變更推送至正式環境。
以永久服務或 sidecar 的形式執行 Auth Proxy 用戶端
在正式環境中，您應將 Auth Proxy 用戶端做為永久服務或 sidecar 執行。
如果 Auth Proxy 用戶端程序停止，系統會中斷所有透過該程序建立的現有連線，且應用程式無法再使用 AlloyDB Auth Proxy 建立與 AlloyDB 執行個體的連線。為避免這種情況，請將 Auth Proxy 用戶端做為永久服務執行，這樣一來，如果 Auth Proxy 用戶端因任何原因結束，就會自動重新啟動。
根據您執行用戶端的位置，使用下列選項：
- 如果 Auth Proxy 用戶端在 Linux VM 上執行，請使用
systemd、upstart或supervisor等服務。 - 如果是 Windows 工作負載，請將 Auth Proxy 用戶端做為 Windows 服務執行。詳情請參閱「以 Windows 服務的形式執行 Auth Proxy」。
- 如果是 Kubernetes 設定，請以 sidecar 形式執行 Auth Proxy 用戶端。
在與工作負載相同的機器上執行 Auth Proxy 用戶端
Auth Proxy 用戶端會假設其與工作負載在同一部機器上執行。任何傳送至驗證 Proxy 的用戶端流量都不會加密。從 Auth Proxy 傳送至 AlloyDB 的流量會使用 mTLS 加密。
請確認驗證 Proxy 的所有用戶端都位於同一部機器上，以免未加密的流量離開機器。AlloyDB Auth Proxy 應與要存取 AlloyDB 執行個體的用戶端位於相同位置。
為每項工作負載使用不同的服務帳戶
AlloyDB Auth Proxy 會使用環境的 Identity and Access Management (IAM) 主體，建立連往 AlloyDB 執行個體的安全通道。為遵循最小權限原則，每個工作負載 (例如網頁應用程式或後端資料處理應用程式) 都必須使用不同的服務帳戶。使用不同的服務帳戶，可確保每項工作負載的權限都能分開管理 (或撤銷)。
請勿將 AlloyDB Auth Proxy 部署為瓶頸
您可能會想在共用 VM 上部署 AlloyDB Auth Proxy，並用來將多個工作負載的所有流量轉送至 AlloyDB 執行個體。不過，這種做法並不安全，而且會造成單點故障。
如果多個用戶端最終使用與 Auth Proxy 相同的 IAM 主體，就很難找出實際存取 AlloyDB 執行個體的工作負載，因此這種做法並不安全。
這種做法會造成單點故障，因為如果 AlloyDB Auth Proxy 因流量暴增而超載，所有用戶端連線都會受到負面影響。
請改為在每部需要安全連線的機器上，部署驗證 Proxy 用戶端，做為 Sidecar 或永久服務。
減少正式環境部署作業的 AlloyDB Auth Proxy 記錄輸出
如要限制 AlloyDB Auth Proxy 記錄的大小，請在啟動 AlloyDB Auth Proxy 時設定 --verbose=false 選項。請注意，使用這個選項會降低 AlloyDB Auth Proxy 輸出內容在診斷連線問題時的有效性。
閱讀 AlloyDB Auth Proxy 說明訊息
AlloyDB Auth Proxy 包含許多額外功能，並提供詳盡的說明訊息。執行 alloydb-auth-proxy --help 指令，探索其他設定選項。
在 GitHub 上與開發團隊互動
如果您認為自己發現了錯誤或有功能要求，可以前往 AlloyDB Auth Proxy GitHub 存放區與開發團隊聯絡。