Cloud SQL Postgres无超级用户权限时如何阻止新用户创建表

执行REVOKE CREATE ON SCHEMA public FROM public时触发WARNING: no privileges could be revoked for "public"报错的本质，是Cloud SQL的权限隔离设计导致的：标准Postgres环境中public schema的属主是数据库管理员账号，但Cloud SQL为避免用户误操作影响平台内置能力，将public schema的属主调整为了平台内置的管理角色，你持有的Cloud SQL高权限非超级用户账号，没有修改该schema原有授权记录的权限，因此revoke操作没有可操作的权限目标，最终触发警告且操作不生效。

可落地实现方案（全程不需要超级用户权限） #

方案1：自建独立业务schema实现完全自主权限管控 #

这是兼容性最强、稳定性最高的通用方案，所有操作都可以用Cloud SQL创建实例时生成的最高权限账号完成：

• 用高权限账号创建专属业务schema，例如执行CREATE SCHEMA app_core;，该schema的属主就是你的账号，你对这个对象拥有全量控制权限，不受平台内置权限的限制
• 直接对自建schema回收全局建表权限：执行REVOKE CREATE ON SCHEMA app_core FROM PUBLIC;——因为你是schema属主，该操作完全合规，不会触发权限报错
• 新建普通业务用户时，强制调整用户的默认搜索路径，把public schema从建表路径中排除：执行ALTER ROLE 业务用户名 SET search_path TO app_core, pg_catalog;
• 按需给业务用户分配schema的使用权限，明确不开放建表权限：GRANT USAGE ON SCHEMA app_core TO 业务用户名;
• 这套方案完全绕开了你无权限管控的public schema，普通用户既无法在自建schema下创建新对象，默认连接时也不会触发public schema的建表逻辑。

方案2：自定义角色组实现批量权限隔离 #

配合自建schema的权限模型，可以通过角色组简化多用户的权限管控流程：

• 创建专属的受控用户组角色：CREATE ROLE app_user_group NOINHERIT;
• 按照权限最小化原则，只给这个角色组分配业务schema的USAGE权限，绝不分配CREATE权限
• 所有新建普通业务用户，都直接加入这个角色组：GRANT app_user_group TO 业务用户名;
• 针对public schema的残留权限，可以通过创建事件触发器做兜底拦截：只要检测到属于普通用户组的账号尝试在public schema下创建表或其他对象，直接抛出权限错误。该操作在Cloud SQL内置的高权限非超级用户角色下可正常执行，不需要真正的系统级超级权限。

方案3：Cloud SQL平台侧配置调整 #

如果你的实例是PostgreSQL 15及以上版本，可以直接通过Cloud SQL控制台的数据库配置入口，调整public schema的默认授权规则。该操作由平台服务侧代为执行，不需要你持有实例的超级用户权限，调整完成后可以实现和本地Postgres环境下执行REVOKE CREATE ON SCHEMA public FROM public完全一致的效果。

内容的提问来源于stack exchange，提问作者Code