解读

面试官想知道你是否真正动手用过 Cloud SQL Auth Proxy，能否把“认证链路”与“代理启动参数”这两个维度拆开讲清楚。国内候选人在回答时，常把“IAM 认证”与“Proxy 自动取令牌”混为一谈，或者误以为“只要配了 IAM 就能完全不用密码”，导致落地时踩坑。面试官期待你给出可验证、可灰度、可回滚的最佳实践，而不是背文档。

知识点

1. 代理启动时的认证源优先级

   1. 若命令行显式给出 -enable_iam_login（或 v2 版本的 --auto-iam-authn），Proxy 会强制走 IAM 数据库身份认证，此时静态密码参数被忽略。
   2. 若未开启 IAM 标志，Proxy 退回到静态密码模式，依次读取：
      a. 命令行 -u user -p pass
      b. 环境变量 CLOUDSQL_USER / CLOUDSQL_PASSWORD
      c. 本地凭据文件 ~/.my.cnf（MySQL）或 ~/.pgpass（PostgreSQL）
   3. 如果以上均无，Proxy 仍可通过已登录的 gcloud Application Default Credentials (ADC) 去拉取实例级连接令牌，但不会代替数据库用户密码；这一步仅用于建立到 Cloud SQL 实例的隧道，与数据库内身份认证无关。

2. 数据库侧开关决定 IAM 认证是否真正生效
   即使 Proxy 带了 -enable_iam_login，如果实例级标志 cloudsql.iam_authentication 为 OFF，或者用户未被授予 roles/cloudsql.instanceUser / cloudsql.instances.login 角色，连接会在数据库握手阶段被驳回，报错 FATAL: IAM authentication is not enabled for this instance。此时不会回退到密码，连接直接失败，体现fail-fast 原则。

3. 国内网络环境下的补充细节
   由于跨境链路延迟，Proxy 默认走 HTTPS 443 出口获取 IAM 令牌；若公司出口做白名单限制，需额外放行 oauth2.googleapis.com 与 sqladmin.googleapis.com，否则会出现令牌 403 而误判为 IAM 优先级问题。
   在Private IP 场景下，Proxy 仍然需要先公网拿到令牌，再经VPC Peering 走内网连实例；因此IAM 认证优先级不受网络模式影响，但令牌获取环节必须能出公网，或在内网部署 Private Service Connect 反向代理。

答案

Cloud SQL Auth Proxy 的认证优先级由**“是否显式开启 IAM 标志”**这一位决定：

• 一旦在启动参数里打开 -enable_iam_login（或 v2 的 --auto-iam-authn），Proxy 强制使用自动 IAM 认证，静态密码字段被完全忽略，此时连接成功的前提有三：
  1. 实例已开启 cloudsql.iam_authentication；
  2. 用户拥有 roles/cloudsql.instanceUser 或更高权限；
  3. 运行环境能正常换取 OAuth2 访问令牌。
• 若未开启 IAM 标志，Proxy 退回到传统静态密码链路，按“命令行 > 环境变量 > 本地凭据文件”顺序取值，不会尝试 IAM 认证，也不会因 IAM 配置缺失而报错。
  因此，IAM 认证与静态密码在代理内部是互斥的，优先级由启动开关一次性决定，不存在运行时回退；这是与国内自建 MySQL “先插件后本机”那种可回退机制最大的差异。

拓展思考

1. 灰度迁移方案：
   在国内金融客户场景，可先用 数据库双账号 方案灰度：

   • 同一数据库创建 app_user（静态密码）与 app_user_iam（IAM 类型）；
   • 应用在配置中心加开关，通过 Proxy 的不同启动参数分别指向两个账号；
   • 利用 Cloud SQL 的审计日志 对比 authentication_method 字段，确认无失败记录后，再下线密码账号，实现零停机割接。

2. Terraform 模板固化优先级：
   把 -enable_iam_login 是否出现做成 Terraform 变量 var.use_iam_authn，同时在 google_sql_user 资源里用 for_each 动态创建 IAM 用户或传统用户，一套代码同时输出两套 Proxy 启动脚本，方便蓝绿发布与快速回滚。

3. 最小权限原则：
   国内等保要求“谁接入谁负责”，建议为 Proxy 单独创建 服务账号，只授予

   • roles/cloudsql.client（连接实例）
   • roles/iam.serviceAccountTokenCreator（换取令牌）
     两个角色，杜绝项目级 Editor 滥用，并在 VPC Service Controls 里把该服务账号加入可信访问级别，防止离职人员带走密钥造成横向移动。