本页列出了使用 AlloyDB Auth Proxy 的一些最佳实践。
确保 Auth 代理客户端为最新版本
Google 每月发布一次 Auth 代理的新版本。您可以查看 AlloyDB Auth 代理 GitHub 版本页面，了解当前版本。
先使用自动化功能更新 Auth 代理版本并在非生产环境中测试新版本，然后再将更改推送到生产环境。
将 Auth Proxy 客户端作为永久性服务或 Sidecar 运行
在生产环境中，您应将 Auth Proxy 客户端作为永久性服务或 Sidecar 运行。
如果 Auth 代理客户端进程停止，则通过该进程建立的所有现有连接都会被舍弃，且您的应用无法再使用 AlloyDB Auth 代理创建与 AlloyDB 实例的任何连接。为避免出现这种情况，请将 Auth Proxy 客户端作为永久性服务运行，以便在 Auth Proxy 客户端因任何原因退出时自动重启。
根据您运行客户端的位置，使用以下选项：
- 对于在 Linux 虚拟机上运行的 Auth 代理客户端，请使用
systemd、upstart或supervisor等服务。 - 对于 Windows 工作负载，请将 Auth 代理客户端作为 Windows 服务运行。如需了解详情，请参阅 Windows 服务指南。
- 对于 Kubernetes 设置，请将 Auth Proxy 客户端作为 Sidecar 运行。
在与工作负载位于同一台机器上运行 Auth 代理客户端
Auth 代理客户端假定它与工作负载在同一台机器上运行。发送到 Auth 代理的任何客户端流量都不会加密。从 Auth Proxy 到 AlloyDB 的流量使用 mTLS 加密。
确保身份验证代理的所有客户端都位于同一台机器上，以便没有未加密的流量离开该机器。AlloyDB Auth Proxy 应与想要访问 AlloyDB 实例的客户端共存。
为每个工作负载使用不同的服务账号
AlloyDB Auth Proxy 使用环境的 IAM 正文创建一个到 AlloyDB 实例的安全隧道。为遵循最小权限原则，每个工作负载（例如 Web 应用或后端数据处理应用）都必须使用不同的服务账号。使用不同的服务账号可确保能够单独管理（或撤消）每个工作负载的权限。
请勿将 AlloyDB Auth 代理部署为瓶颈
您可能很想在共享虚拟机上部署 AlloyDB Auth 代理，并使用它将来自多个工作负载的所有流量路由到 AlloyDB 实例。不过，这种方法不安全，会造成单点故障。
由于多个客户端最终会使用 Auth Proxy 使用的相同 IAM 主账号，因此很难确定实际访问 AlloyDB 实例的工作负载，这使得这种方法不安全。
这种方法会造成单点故障，因为如果 AlloyDB Auth Proxy 因突发流量而超载，所有客户端连接都会受到负面影响。
而是在需要安全连接的每台机器上部署 Auth Proxy 客户端，作为持久性服务的 Sidecar 进行部署。
减少生产部署的 AlloyDB Auth 代理日志输出
如果您需要限制 AlloyDB Auth 代理日志的大小，请在启动 AlloyDB Auth 代理时设置 --verbose=false 选项。请注意，使用此选项会降低 AlloyDB Auth 代理输出在诊断连接问题时的有效性。
阅读 AlloyDB Auth 代理帮助消息
AlloyDB Auth 代理包含许多其他功能，并附有详细的帮助消息。运行 ./alloydb-auth-proxy --help 命令可查看其他配置选项。
在 GitHub 上与开发团队互动
如果您认为自己发现了 bug 或有功能请求，可以通过 AlloyDB Auth Proxy 的 GitHub 代码库与开发团队联系。