[[["易于理解","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-25。"],[[["\u003cp\u003eKeep the AlloyDB Auth Proxy client updated by automating the update process and testing new versions in non-production environments before deploying to production.\u003c/p\u003e\n"],["\u003cp\u003eRun the Auth Proxy client as a persistent service or sidecar to prevent connection drops and ensure automatic restarts in case of failure.\u003c/p\u003e\n"],["\u003cp\u003eDeploy the Auth Proxy client on the same machine as the workload to maintain security and prevent unencrypted traffic from leaving the machine.\u003c/p\u003e\n"],["\u003cp\u003eUse a distinct service account for each workload to adhere to the principle of least privilege and enable granular permission management.\u003c/p\u003e\n"],["\u003cp\u003eAvoid deploying the Auth Proxy as a bottleneck by deploying an Auth Proxy client on each machine requiring a secure connection, preventing a single point of failure and insecurity.\u003c/p\u003e\n"]]],[],null,["# Best practices for using the AlloyDB Auth Proxy\n\nThis page lists some best practices for using the AlloyDB Auth Proxy.\n\nKeep the Auth Proxy client up-to-date\n-------------------------------------\n\nGoogle releases new versions of the Auth Proxy monthly. You can find\nthe current version by checking the [AlloyDB Auth Proxy GitHub releases\npage](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy/releases).\n\nUse automation to update the Auth Proxy version and test the new\nversion in non-production environments before promoting the change to\nproduction.\n\nRun the Auth Proxy client as a persistent service or sidecar\n------------------------------------------------------------\n\nIn production, you should run the Auth Proxy client as a persistent service\nor sidecar.\n\nIf the Auth Proxy client process is stopped,then all existing connections\nthrough it are dropped, and your application cannot create any more connections\nto the AlloyDB instance with the AlloyDB Auth Proxy. To prevent this\nscenario, run the Auth Proxy client as a persistent service, so that if the\nAuth Proxy client exits for any reason, it is automatically restarted.\n\nBased on where you are running the client, use the following options:\n\n- For Auth Proxy client running on Linux VMs, use a service such as `systemd`, `upstart`, or `supervisor`.\n- For Windows workloads, run the Auth Proxy client as a Windows Service. See the [Windows Service Guide](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy/blob/main/windows-service-guide.md) for more information.\n- For Kubernetes setups, run the Auth Proxy client as a sidecar.\n\nRun the Auth Proxy client on the same machine as your workload\n--------------------------------------------------------------\n\nThe Auth Proxy client assumes it runs on the same machine as the workload.\nAny client traffic to the Auth Proxy will be unencrypted. Traffic from\nthe Auth Proxy to the AlloyDB is encrypted using mTLS.\n\nMake sure any client of the Auth Proxy is\nlocated on the same machine so that no unencrypted traffic leaves the\nmachine. The AlloyDB Auth Proxy should be co-located with a client\nthat wants to access your AlloyDB instance.\n\nUse a distinct service account for each workload\n------------------------------------------------\n\nThe AlloyDB Auth Proxy uses the environment's IAM principal to create a secure\ntunnel to an AlloyDB instance. To follow the principle of least\nprivilege, each workload, such as a web app or a backend data processing app,\nmust use a distinct service account. The use of distinct service account ensures\nthat each workload's permissions can be managed (or revoked) separately.\n\nDon't deploy the AlloyDB Auth Proxy as a bottleneck\n---------------------------------------------------\n\nIt may be tempting to deploy the AlloyDB Auth Proxy on a shared VM and use it to\nroute all traffic from a number of workloads to your AlloyDB instance.\nHowever, this approach is insecure and creates a single point of failure.\n\nAs multiple clients end up using the same IAM principal that\nAuth Proxy uses, identifying the workload that is actually accessing\nyour AlloyDB instance becomes difficult, making this approach\ninsecure.\n\nThis approach creates a single point of failure because if the AlloyDB Auth Proxy is\noverloaded with a burst of traffic, all client connections will be negatively\naffected.\n\nInstead, deploy an Auth Proxy client on each machine that needs a\nsecure connection either as a sidecar of persistent service.\n\nReduce AlloyDB Auth Proxy log output for production deployments\n---------------------------------------------------------------\n\nIf you need to limit the size of the AlloyDB Auth Proxy logs, then set the\n`--verbose=false` option when you start the AlloyDB Auth Proxy. Note that using this\noption reduces the effectiveness of the AlloyDB Auth Proxy output in diagnosing\nconnection issues.\n\nRead the AlloyDB Auth Proxy help message\n----------------------------------------\n\nThe AlloyDB Auth Proxy includes many additional features and includes an extensive\nhelp message with details. Run the `./alloydb-auth-proxy --help` command to\ndiscover additional configuration options.\n\nEngage with the development team on GitHub\n------------------------------------------\n\nIf you believe you have found a bug or have a feature request, then you may\nengage with the development team on [AlloyDB Auth Proxy's GitHub\nrepository](https://github.com/GoogleCloudPlatform/alloydb-auth-proxy)."]]
