ClickHouse Cloud 中的访问控制

ClickHouse 在两个地方控制用户访问，通过控制台和通过数据库。控制台访问通过 clickhouse.cloud 用户界面管理。数据库访问通过数据库用户帐户和角色管理。此外，控制台用户可以被授予数据库中的角色，这些角色使控制台用户能够通过我们的 SQL 控制台与数据库交互。

角色类型

以下描述了可用的不同类型的角色

• 控制台角色 启用对 clickhouse.cloud 控制台的访问
• 数据库角色 启用单个服务内权限的管理
• SQL 控制台角色 特殊命名的数据库角色，使控制台用户能够通过 SQL 控制台访问具有分配权限的数据库。

预定义角色

ClickHouse Cloud 提供数量有限的预定义角色来启用访问管理。可以使用数据库中的 CREATE ROLE 和 GRANT 命令随时创建其他自定义数据库角色。

上下文	角色名称	描述
控制台	管理员	对 ClickHouse 组织的完全访问权限
控制台	开发者	对 ClickHouse 组织的只读访问权限
SQL 控制台	sql_console_admin	对数据库的管理员访问权限
SQL 控制台	sql_console_read_only	对数据库的只读访问权限
数据库	default	对数据库的管理员访问权限；在服务创建时自动授予 default 用户

初始设置

第一个设置 ClickHouse Cloud 帐户的用户会自动在控制台中分配管理员角色。此用户可以邀请其他用户加入组织，并为用户分配管理员或开发者角色。

注意

要更改用户在控制台中的角色，请转到左侧的“用户”菜单，并在下拉菜单中更改用户角色。

数据库有一个名为 default 的帐户，该帐户会自动添加并在服务创建时授予 default_role。创建服务的用户会收到自动生成的随机密码，该密码在服务创建时分配给 default 帐户。在初始设置后不会显示密码，但稍后任何具有控制台管理员权限的用户都可以更改它。此帐户或控制台中具有管理员权限的帐户可以随时设置其他数据库用户和角色。

注意

要更改分配给控制台中 default 帐户的密码，请转到左侧的“服务”菜单，访问服务，转到“设置”选项卡，然后单击“重置密码”按钮。

我们建议创建一个与人员关联的新用户帐户，并授予该用户 default_role。这样做的目的是为了识别用户执行的活动与其用户 ID，并将 default 帐户保留用于紧急情况类型的活动。

CREATE USER userID IDENTIFIED WITH sha256_hash by 'hashed_password';
GRANT default_role to userID;

用户可以使用 SHA256 哈希生成器或 Python 中的 hashlib 等代码函数将具有适当复杂度的 12 个以上字符的密码转换为 SHA256 字符串，并将其提供给系统管理员作为密码。这可确保管理员看不到或处理明文密码。

控制台角色

必须为控制台用户分配角色，并且可以为其分配管理员或开发者角色。下面包含与每个角色关联的权限。

组件	功能	管理员	开发者
管理服务	查看服务	✅	✅
	创建服务	✅	❌
	删除服务	✅	❌
	停止服务	✅	❌
	重新启动服务	✅	❌
	重置服务密码	✅	❌
	查看服务指标	✅	✅
云 API	查看 API 密钥记录	✅	✅
	创建 API 密钥	✅	只读
	删除 API 密钥	✅	自己的密钥
管理控制台用户	查看用户	✅	✅
	邀请用户	✅	❌
	更改用户角色	✅	❌
	删除用户	✅	❌
计费、组织和支持	查看计费	✅	✅
	管理计费	✅	❌
	查看组织活动	✅	❌
	提交支持请求	✅	✅
	查看集成	✅	✅

SQL 控制台角色

我们的控制台包含一个 SQL 控制台，用于使用无密码身份验证与数据库交互。在控制台中被授予管理员权限的用户可以管理组织中的所有数据库。被授予开发者角色的用户默认情况下没有访问权限，但可以从控制台中分配“完全访问权限”或“只读”数据库权限。“只读”角色最初授予帐户只读访问权限。但是，一旦授予只读访问权限，就可以为该 SQL 控制台用户专门创建一个新的自定义角色，该角色将在用于通过 SQL 控制台连接到数据库时与该用户关联。

注意

要允许控制台中具有开发者角色的用户访问 SQL 控制台，请转到左侧的“服务”菜单，访问服务，单击“设置”，向下滚动到 SQL 控制台访问部分，然后选择“完全访问权限”或“只读”。授予访问权限后，使用下面**创建 SQL 控制台角色**中显示的过程分配自定义角色。

更多关于无密码身份验证的信息

为每个会话创建 SQL 控制台用户，并使用自动轮换的 X.509 证书进行身份验证。会话终止时，用户将被删除。在为审计生成访问列表时，请导航到控制台中服务的“设置”选项卡，并注意 SQL 控制台访问以及数据库中存在的数据库用户。如果配置了自定义角色，则用户的访问权限列在以用户名结尾的角色中。

创建 SQL 控制台角色

可以创建自定义角色并将其与 SQL 控制台用户关联。由于 SQL 控制台每次用户打开新会话时都会创建一个新的用户帐户，因此系统使用角色命名约定将自定义数据库角色与用户关联。这意味着每个用户都分配了一个单独的角色。然后可以通过 GRANT 语句直接为各个角色分配访问权限，或者用户可以建立新的通用角色（例如 database_developer 或 security_administrator），并通过更通用的角色为各个用户角色分配访问权限。

要为 SQL 控制台用户创建自定义角色并为其授予通用角色，请运行以下命令。电子邮件地址必须与控制台中的用户电子邮件地址匹配。

1. 创建 database_developer 角色并授予 SHOW、CREATE、ALTER 和 DELETE 权限。

CREATE ROLE OR REPLACE database_developer;
GRANT SHOW ON * TO database_developer;
GRANT CREATE ON * TO database_developer;
GRANT ALTER ON * TO database_developer;
GRANT DELETE ON * TO database_developer;

2. 为 SQL 控制台用户 [email protected] 创建一个角色，并为其分配 database_developer 角色。

CREATE ROLE OR REPLACE `sql-console-role:[email protected]`;
GRANT database_developer TO `sql-console-role:[email protected]`;

使用此角色构造时，需要修改显示用户访问权限的查询，以在用户不存在时包含角色到角色的授权。

SELECT grants.user_name,
  grants.role_name,
  users.name AS role_member,
  grants.access_type,
  grants.database,
  grants.table
FROM system.grants LEFT OUTER JOIN system.role_grants ON grants.role_name = role_grants.granted_role_name
  LEFT OUTER JOIN system.users ON role_grants.user_name = users.name

UNION ALL

SELECT grants.user_name,
  grants.role_name,
  role_grants.role_name AS role_member,
  grants.access_type,
  grants.database,
  grants.table
FROM system.role_grants LEFT OUTER JOIN system.grants ON role_grants.granted_role_name = grants.role_name
WHERE role_grants.user_name is null;

数据库角色

也可以使用 CREATE User、CREATE Role 和 GRANT 语句直接在数据库中创建用户和自定义角色。除了为 SQL 控制台创建的角色之外，这些用户和角色独立于控制台用户和角色。

数据库角色是累加的。这意味着如果用户是两个角色的成员，则用户拥有授予这两个角色的最多的访问权限。通过添加角色，他们不会失去访问权限。

可以将数据库角色授予其他角色，从而形成分层结构。角色继承其所属角色的所有权限。

数据库角色每个服务都是唯一的，并且可以应用于同一服务内的多个数据库。

下图显示了可以授予用户权限的不同方式。