概述
- 服务账号可以被分配多个角色,但只需激活特定查询所需的那个角色。
- 如果服务账号被攻破,攻击者也只能使用当前激活角色的权限。
- 单个账号可以通过切换角色来执行不同任务,而不必为每项任务分别使用单独的凭据。
- 只需修改一个角色,而无需逐个更新用户,即可为整类服务账号更新权限。
- 日志可以记录查询期间具体激活的是哪个角色,从而为安全审计提供更清晰的上下文。
- 设计用于定义允许范围边界的角色 (如 read_only、maintenance 等)
- 将这些角色授予服务账号
- 在建立连接时,通过
SET ROLE(或 role 参数) 选择激活的角色,从而限制该会话可执行的操作
设置服务角色
1
将角色授予服务账号
首先,创建具有所需特权/设置的角色,然后将其授予服务账号。
2
使用 SET ROLE 定义权限边界
在会话开始时,服务账号可以选择激活哪些角色:或:或启用多个角色:当前激活角色可通过
SET ROLE 会为当前用户启用角色;生效的特权是所有激活角色特权的并集,再加上直接授予该用户的任何特权。你也可以禁用所有角色:system.current_roles 查看。3
为服务账号设置默认角色
为确保服务账号始终以受限模式启动,请配置默认角色:或
4
通过 HTTP / 以编程方式使用 SET ROLE
如果服务账号通过 HTTP 连接,则不能将 SET ROLE; SELECT … 作为多条语句发送。应改为将角色作为查询参数传递:
?role=… 等同于在该语句之前执行 SET ROLE read_only_role。多个角色参数的行为类似于 SET ROLE role 1, role 2。一些驱动程序 (例如用于 Python 的 ClickHouse Connect) 也提供角色设置,并会随每个请求一并发送,服务器会将其用作会话角色。