解读

在国内金融、政企及互联网面试中，面试官问“同名冲突”并不是想听你背文档，而是考察两点：

1. 是否真正在生产环境用过 Cloud SQL IAM 集成认证，还是只停留在“会开实例”；
2. 能否在 零信任架构 下，把 IAM 身份、数据库用户、Least Privilege 原则串起来讲清楚。
   因此，回答必须给出 确定的优先级顺序，并解释 为什么 Google 这样设计，再补一句国内合规场景下的 风险兜底方案。

知识点

1. Cloud SQL 的两种认证通道

   • IAM 数据库认证（IAM DB Auth）：走 OAuth2 访问令牌，由 Cloud SQL Auth Proxy 或 SSL 证书完成握手，不校验 PostgreSQL/MySQL 自身密码。
   • 传统数据库认证（Built-in Auth）：走实例内部 pg_shadow/mysql.user 表，必须提供用户名+密码。

2. 同名冲突时的判定逻辑
   当客户端连接字符串里出现相同用户名（如 postgres 或 root）时，实例先检查 该用户是否被授予了 cloudsql.iam_authentication 角色（PostgreSQL）或对应 IAM 权限（MySQL）。

   • 若 已授予，则 强制走 IAM 认证通道，传统密码被忽略；
   • 若 未授予，则 回落到 Built-in 认证，必须输密码。
     因此优先级可以总结为：IAM 认证 > Built-in 认证，不以连接参数顺序而以 IAM 授权标记为准。

3. 国内落地注意点

   • 等保 2.0 要求“双重认证”，所以即使开了 IAM，也建议 保留 Built-in 超级用户并托管在 Secret Manager，用于应急。
   • 政企项目常把 域控账号同步到 Cloud Identity，同名冲突概率更高，务必在 Terraform 模板里 显式关闭 iam_authentication，或给用户名加前缀（如 iam_xxx）来规避误用。

答案

IAM 认证优先。
只要该数据库用户名被授予了 roles/cloudsql.instanceUser（或对应旧版 cloudsql.iam_authentication 角色），Cloud SQL 实例会 强制使用 IAM 令牌认证，传统密码即使提供也会被忽略；
若同名用户 没有 IAM 授权，则 回落到 Built-in 认证，必须输入正确密码才能登录。
因此“同名”不会导致冲突，优先级由 IAM 授权开关决定，IAM 通道始终排在前面。

拓展思考

1. 如果面试官追问“怎么让 DBA 既能用 IAM 登录，又能在 IAM 失效时抢修”，可以答：
   创建两个账号：dba_iam 开 IAM 认证用于日常，保留原生 dba_root 账号并把密码托管在 Secret Manager + CMEK 加密，通过 VPC-SC 边界限制调用，实现 应急双轨。

2. 国内多云混合场景下，建议 用 Cloud SQL Auth Proxy 的 -enable_iam_login 参数 做 一次性令牌刷新，避免把长期密钥落在 K8s Secret 里，既满足 银保监会对密钥轮换 的要求，也兼容 DevOps 一键发布。