PostgreSQL延迟查询任务中避免存储用户密码的方案探讨

一、优化你提出的「视图+临时账户」方案 #

你的思路本身已经具备不错的安全性，可以通过以下细节优化进一步降低风险：

• 严格绑定账户生命周期：任务提交时创建临时账户，直接设置密码有效期为任务预计执行时间+1小时缓冲（用ALTER ROLE temp_user VALID UNTIL '任务执行时间+1h'），或者在任务执行完成后立即执行DROP ROLE IF EXISTS temp_user删除账户。就算凭证泄露，有效期极短，危害范围也会被限制。
• 最小化权限范围：创建视图时只包含用户查询所需的列，不给临时账户任何额外权限——连数据库连接权限都可以通过pg_hba.conf限制为仅允许你的系统服务器IP访问。如果用临时视图（pg_temp schema下），任务执行后会自动清理，不用在主schema下留存冗余对象。
• 避免持久化视图：动态创建pg_temp临时视图，该视图仅在当前会话有效，任务执行完会话关闭后自动消失，无需手动清理。

二、无凭证存储的即时权限委托方案 #

这个方案彻底避免存储任何用户凭证，核心是把权限管理延迟到任务执行前：

• 系统维护一个拥有最小必要权限的服务账户（比如仅能创建临时角色、授予SELECT权限），不要用超级账户。
• 用户提交任务时，系统先用用户提供的Postgres凭证尝试建立一次连接，执行简单校验（比如SELECT current_user确认身份），验证通过后立即丢弃原始凭证，只存储查询语句、用户身份标识等元数据。
• 任务执行时，系统用服务账户连接Postgres：
  1. 创建临时角色，仅授予该用户查询目标表/列的SELECT权限；
  2. 通过SET ROLE temp_role切换到临时角色执行查询；
  3. 查询完成后，立即删除临时角色。
• 优势：全程不碰用户密码，临时权限仅在执行期间存在，风险极低；缺点：任务执行时需要额外的权限操作步骤，对系统并发处理能力有一定要求。

三、基于角色继承的临时权限方案 #

如果你的系统能控制Postgres配置，这个方案更轻量：

• 用户提交任务并验证凭证有效后，系统创建一个临时角色（比如temp_task_123），让它继承用户的原始角色，但通过REVOKE回收无关权限，只保留目标查询所需的SELECT权限。
• 给临时角色设置短期有效密码，执行任务时用这个临时角色登录，执行完成后立即删除角色。
• 这个方案不用创建视图，直接基于用户原有权限子集生成临时权限，适合查询逻辑简单的场景。

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