如何自动化为每个租户创建 schema 并授予受限权限？ - 问题详情 - 创脉思

解读

在国内多租户 SaaS 场景里，“一租户一 schema” 是常见的数据隔离模型。面试官问这道题，核心想验证三件事：

你是否理解 Cloud SQL 的权限体系（IAM ≠ 数据库 RBAC）；
能否把“创建 schema + 授权”做成可重复、可审计、零人工的流程；
是否具备安全合规意识，防止租户越权或误操作。

因此，答案必须覆盖：自动化触发、最小权限、审计、灰度、回滚、成本六大维度，并给出可直接落地的 Google Cloud 原生方案。

知识点

Cloud SQL 不提供“schema 级”IAM 角色，所有数据库权限必须用 SQL GRANT 完成；
连接方式优先用 Cloud SQL Auth Proxy + IAM 数据库身份验证，避免在代码里硬编码密码；
自动化编排选 Cloud Workflows + Cloud Functions（2nd Gen），全托管、按调用计费，符合国内对“不碰运维”的诉求；
把“建 schema 脚本”和“授权脚本”拆成两步，先 REVOKE 再 GRANT，保证幂等；
国内备案要求日志至少保存 180 天，需开启 Cloud SQL 的 pgaudit 或 general_log，并导出到 Cloud Logging + Log Router 至国内 Region 的 BigQuery；
如果租户数量 >5 000，建议把“schema 元数据”存进 Firestore，用 Cloud Workflows 做 Map Reduce，防止单函数 9 分钟超时；
灰度发布用 Cloud Deploy 的 Cloud SQL 阶段策略，可回滚到指定 schema 版本；
成本优化：给函数配 最小 256 MB 内存 + 并发 1，并把 Cloud SQL 实例设为 db-f1-micro 共享 CPU，开发环境可省 70% 费用。

答案

整体架构
Cloud Workflows → Cloud Functions（2nd Gen）→ Cloud SQL（PostgreSQL 13+）
Workflows 负责编排，函数负责执行 SQL，Cloud SQL 开 IAM 身份验证，禁止任何本地账号。
准备工作
a. 创建 专用的 Google Service Account：sa-schema-admin@project.iam.gserviceaccount.com，授予角色 Cloud SQL Client + Service Usage Consumer。
b. 在 Cloud SQL 实例里把该 SA 加为 cloudsqlsuperuser，但后续只给它 CREATEROLE 与 CREATEDB 两个属性，不授予 SUPERUSER，防止误删系统表。
c. 启用 pgaudit.log = 'all, -misc'，日志写入国内 shanghai Region 的 BigQuery 数据集，满足审计合规。
函数代码（Python 3.11，精简核心）
函数入口接收 JSON：{"tenant_id":"t123456","region":"shanghai"}
使用 SQLAlchemy 2.0 + pg8000 驱动，通过 Connector() 自动 IAM 鉴权，连接串无需密码。
执行模板：
```
CREATE SCHEMA IF NOT EXISTS t123456;
GRANT USAGE ON SCHEMA t123456 TO "t123456_app";
GRANT CREATE ON SCHEMA t123456 TO "t123456_app";
ALTER DEFAULT PRIVILEGES IN SCHEMA t123456 GRANT SELECT,INSERT,UPDATE,DELETE ON TABLES TO "t123456_app";
ALTER DEFAULT PRIVILEGES IN SCHEMA t123456 GRANT USAGE,SELECT ON SEQUENCES TO "t123456_app";
```
每条 SQL 前自动加 BEGIN; SET LOCAL ROLE cloudsqlsuperuser; … COMMIT;，确保事务原子。
执行完把结果写入 Firestore 集合 tenant_schema/{tenant_id}，字段包括 created_at、schema_name、sql_sha256，用于幂等校验。
Workflows 编排
- 步骤 1：调用 Cloud Functions 创建 schema；
- 步骤 2：调用 Cloud Functions 校验 information_schema.schemata 是否已存在；
- 步骤 3：把事件推送到 Pub/Sub 主题 tenant-schema-ready，供业务微服务订阅；
- 步骤 4：失败时进入 “补偿” 分支，自动执行 DROP SCHEMA IF EXISTS t123456 CASCADE; 并发送 Cloud Monitoring 告警到飞书群（国内常用）。
触发方式
- 生产：业务后台调用 Cloud Run 接口，接口校验 JWT 后触发 Workflows；
- 测试：GitLab CI 通过 gcloud workflows run 命令直接调用，VPC-SC 边界策略限制只能在上海 Region 执行。
安全加固
- 函数实例仅开放 Private IP，通过 Serverless VPC Access Connector 接入 Cloud SQL；
- 在 Cloud Armor 层面对公网调用加 WAF 规则，防止 SQL 注入；
- 所有 SQL 语句提前做 psycopg2.sql.Composed 拼接，禁止字符串格式化，防止二次注入。
灰度与回滚
- 利用 Cloud Deploy 把函数版本与 schema 版本绑定，回滚时自动执行 DROP SCHEMA new_version; ALTER SCHEMA old_version RENAME TO current;
- 回滚窗口设置为 30 分钟，超时自动锁定，防止脏写。
成本估算
- Workflows 每月 1 万次调用，费用约 2.3 元；
- 函数 256 MB 内存，月调用 1 万次，每次 200 ms，费用约 0.4 元；
- Cloud SQL db-f1-micro 开发实例月价 35 元，生产可升 db-n1-standard-2，配合 ** committed use discount** 再省 23%。

拓展思考

如果租户要求跨实例级别隔离，可把“建 schema”升级为“建 Cloud SQL 实例”，用 Cloud SQL Admin API + Terraform 模块 实现，但需注意国内 ICP 备案 一个实例一个域名的问题；
当 schema 数量 >10 000 时，PostgreSQL 的 pg_class catalog 会膨胀，建议定期用 pg_repack 做在线重组，或改用 Cloud Spanner 的“一租户一数据库”模型；
国内金融客户常要求**“国密算法”**，可在 Cloud Functions 层用 Tongsuo（原 BabaSSL）做国密 TLS 反向代理，再连到 Cloud SQL，满足等保 2.0 对传输机密性的要求；
未来若 Google Cloud 在中国推出 Cloud SQL Database Federation + VPC Service Controls，可把“schema 创建”事件直接接入 Security Command Center，实现 实时合规分数 可视化，进一步降低审计人工成本。