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 控制台创建的角色外，这些用户和角色独立于控制台用户和角色。

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

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

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

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