ClickHouse 用户权限管理

小数据自留地 2023-02-07

4348

Clickhouse的用户权限管理体系主要是基于RBAC(Role-based access control), 这一点和ES等其他的数据库体系也类似。我们可以通过服务器配置文件或者SQL驱动这二种方式来管理用户权限，但不能同时使用两个配置的方式来管理，官方文档是建议采用SQL的方式。本文主要介绍的是SQL授权这种方式，采用的CK 22.4.5.9。

default用户和配置文件修改

Clickhouse默认提供一个default用户，使用用户default连接数据库，它具有所有的权限，不需要密码。但却是基于配置文件管理的，这个用户的所有信息都是在 etc/clickhouse-server/users.xml中的。

    <!-- Users and ACL. -->
    <users>
        <!-- If user name was not specified, 'default' user is used. -->
        <default>
            <password></password>
            <networks>
                <ip>::/0</ip>
            </networks>
            <!-- Settings profile for user. -->
            <profile>default</profile>
            <!-- Quota for user. -->
            <quota>default</quota>
            <!-- User can create other users and grant rights to them. -->
            <access_management>1</access_management>
        </default>
    </users>

这个用户有几个配置需要特别注意：

access_management 参数启动SQL方式认证 (1启动 0禁止，默认0)，只有配置了这个后面才能基于SQL进行授权：

            <access_management>1</access_management>

networks默认是向所有网段<ip>::/0</ip>开启的，而且没有密码，这个在生产环境绝对高风险，最好改为只对本地登录开放：

            <networks>
               <ip>127.0.0.1</ip>
            </networks>

除了需要在users.xml文件中修改default用户的默认配置，我们也需要在 /etc/clickhouse-server/config.xml配置用户相关SQL的存储路径：

    <user_directories>
        <local_directory>
            <!-- Path to folder where users created by SQL commands are stored. -->
            <path>/data/clickhouse/access/</path>
        </local_directory>
    </user_directories>

完成了以上基础配置修改以后，我们就可以使用SQL进行授权了。

基于SQL进行授权

SQL的授权流程和其他Mysql，Sentry类似：

创建角色
给角色授权
创建用户
将角色授予给相应的用户

https://kb.altinity.com/altinity-kb-setup-and-maintenance/rbac/#example-3-roles-dba-dashboard_ro-ingester_rw，

这篇文章提供了dba, dashboard_ro, ingester_rw值得作为参考：

首先是做DBA角色的授权，

create role dba on cluster '{cluster}';
grant all on *.* to dba on cluster '{cluster}';
create user `user1` identified  by 'pass1234' on cluster '{cluster}';
grant dba to user1 on cluster '{cluster}';

再看看dashboard_ro角色，可以理解为用于dashboard的只读用户:

create role dashboard_ro on cluster '{cluster}';
grant select on default.* to dashboard_ro on cluster '{cluster}';
grant dictGet on *.*  to dashboard_ro on cluster '{cluster}';


create settings profile or replace profile_dashboard_ro on cluster '{cluster}'
settings max_concurrent_queries_for_user = 10 READONLY, 
         max_threads = 16 READONLY, 
         max_memory_usage_for_user = '30G' READONLY,
         max_memory_usage = '30G' READONLY,
         max_execution_time = 60 READONLY,
         max_rows_to_read = 1000000000 READONLY,
         max_bytes_to_read = '5000G' READONLY
TO dashboard_ro;


create user `dash1` identified  by 'pass1234' on cluster '{cluster}';
grant dashboard_ro to dash1 on cluster '{cluster}';

这里的多加了一个settings profile的例子，并将这个setting profile赋给了dashboard_ro 角色,这里可以看到对读用户的资源使用进行了最大配额的限制。

最后一个例子是ingester_rw，可以当做是flink等应用用户，需要读写权限：

create role ingester_rw on cluster '{cluster}';
grant select,insert on default.* to ingester_rw on cluster '{cluster}';


create settings profile or replace profile_ingester_rw on cluster '{cluster}'
settings max_concurrent_queries_for_user = 40 READONLY,    -- user can run 40 queries (select, insert ...) simultaneously  
         max_threads = 10 READONLY,                        -- each query can use up to 10 cpu (READONLY means user cannot override a value)
         max_memory_usage_for_user = '30G' READONLY,       -- all queries of the user can use up to 30G RAM
         max_memory_usage = '25G' READONLY,                -- each query can use up to 25G RAM
         max_execution_time = 200 READONLY,                -- each query can executes no longer 200 seconds
         max_rows_to_read = 1000000000 READONLY,           -- each query can read up to 1 billion rows
         max_bytes_to_read = '5000G' READONLY              -- each query can read up to 5 TB from a MergeTree
TO ingester_rw;


create user `ingester_app1` identified  by 'pass1234'　on cluster '{cluster}';


grant ingester_rw to ingester_app1 on cluster '{cluster}';

‍

这3个角色基本可以说覆盖了我们用户的常用场景，这里的指令基本上都是on cluster的分布式ddl，但实际测试中还是发现有些命令加上on clutser有问题，不加on cluster的话，需要在每个节点上单独执行。

user local_directory

如果需要在很多个节点上组个执行这些SQL授权命令还是比较麻烦的，在和群里面的大佬们请教了之后，学习到了另外一种办法，直接基于config.xml配置用户相关SQL的存储目录中的数据：

    <user_directories>
        <local_directory>
            <!-- Path to folder where users created by SQL commands are stored. -->
            <path>/data/clickhouse/access/</path>
        </local_directory>
    </user_directories>

我们先看看该目录下的东西：

-rw-r----- 1 clickhouse clickhouse  166 Oct 19 11:35 d24e339a-59af-5f94-a94f-d12db09ecab7.sql
-rw-r----- 1 clickhouse clickhouse  208 Feb  6 09:08 f246a359-ecc2-6dba-554b-5fd4dfb1f18c.sql
-rw-r----- 1 clickhouse clickhouse    1 Oct 17 10:08 quotas.list
-rw-r----- 1 clickhouse clickhouse  129 Feb  6 14:45 roles.list
-rw-r----- 1 clickhouse clickhouse    1 Oct 17 10:08 row_policies.list
-rw-r----- 1 clickhouse clickhouse   54 Oct 19 11:35 settings_profiles.list
-rw-r----- 1 clickhouse clickhouse  173 Feb  6 09:08 users.list

*list后缀结尾是持久化的列表文件，其存储了用户、角色等，每一个用户和角色，都会有一个唯一的ID，都对应这一个ID.sql文件，里面记录了对用户和角色的所有更改。我们就可以通过拷贝access文件夹的方式到新CK节点上进行复制相关用户和权限，这种做法在集群扩容时候更方便，需要注意的是，复制过来的新文件并不会立即生效，需要重启CK server。

文章转载自小数据自留地，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

ClickHouse 用户权限管理

评论