GreptimeDB企业版内置用户管理，助力生产环境实现精细化权限管控。下文将解析其设计思路、启用配置及RBAC与ACL实践，并逐步展示如何操作。

生产环境中，数据库不能仅依赖单一共享账号。不同角色需要差异化访问权限：数据采集管道仅需写入，开发人员仅需查询，管理员则需全面控制。

GreptimeDB开源版已提供基于文件配置的细粒度用户权限管理^[1]，足以应对多数场景。但在企业内部，更细致、更严格的权限管控往往不可或缺。

为此，GreptimeDB企业版内置了一套用户管理系统，无需静态密码文件或外部身份系统，即可在数据库集群内部直接管理用户：账号持久化存储、权限细粒度可控，并配有管理界面。

多数团队的访问控制常从简单起步，随部署深入而日趋复杂。一旦进入生产环境，需求往往发生转变：

1. 数据采集管道不应拥有管理员权限
2. 分析师不能修改数据库
3. 应用服务只能访问自身拥有的表
4. 运维人员需要安全方式长期管理用户

内置用户管理的核心思路，是让GreptimeDB企业版直接接管用户全生命周期：账号持久化至Metasrv的KV存储，在所有Frontend节点间保持一致；每次操作时数据库强制执行权限检查；管理操作通过内置HTTP API和Enterprise Dashboard完成。

以下简要说明该功能的能力与使用方法。

启用功能

要开启内置用户管理，需在GreptimeDB企业版Frontend配置中设置user_provider选项（单机模式则在standalone配置中设置）：

user_provider = "greptime_ee_user_provider:/path/to/passwords.txt"

冒号后路径指向可选账号文件，用于首次启动时导入初始账号。若无需导入任何用户，直接使用greptime_ee_user_provider:即可——注意末尾冒号必须保留，配置解析器有此要求。

若使用官方Helm chart部署，将auth.enabled和auth.useBuiltIn均设为true即可。Chart会根据auth.users生成账号文件（以Kubernetes Secret形式）挂载到实例，并自动完成用户Provider配置。

导入初始账号

账号文件每行定义一个初始账号，格式为username[:role]=password：

# username[:role]=password
admin:admin=admin_pwd
grafana:readonly=grafana_pwd
telegraf:writeonly=telegraf_pwd
writer:readwrite=writer_pwd

格式十分简洁：

1. username为账号名
2. role可选
3. password为初始密码

预定义角色同样一目了然：

1. admin：完整权限，包括用户管理
2. readonly（或ro）：只读
3. writeonly（或wo）：只写
4. readwrite（或rw）：可读可写

省略角色时，默认值为readwrite。导入的用户默认拥有public数据库的完整访问权限。

导入仅在首次启动时执行一次。后续启动若发现账号已存在，GreptimeDB企业版会跳过而非覆盖，之后可通过Enterprise Dashboard修改这些导入的用户。

默认管理员账号

为简化首次部署，GreptimeDB企业版会在系统首次启动时自动创建admin账号（若尚不存在）。

若设置环境变量GREPTIME_ENTERPRISE_ADMIN_PASSWORD，则以该值作为密码；否则系统自动生成随机密码并打印至日志。如此即便尚未创建任何自定义用户，运维人员也能登录新部署集群。管理员密码后续还可通过CLI重置。

关于管理员账号与密码重置的更多细节，请参见文档的参考章节^[2]。

权限与 ACL

内置用户管理模型由两层控制组成。

第一层是基于权限的访问控制（RBAC），它回答：该用户可执行哪类操作？

例如，一个用户可能被允许：

1. 运行查询
2. 写入数据
3. 创建或修改表
4. 管理数据库
5. 执行管理操作

详细的权限定义及预定义角色到权限的映射关系，参见文档的权限与ACL章节^[3]。

第二层是基于ACL的访问控制，它回答：该用户可访问哪些数据库或表？

下图是Enterprise Dashboard中编辑用户的表单，Privileges区域提供预定义角色，Access Control区域支持按表勾选和正则表达式匹配：

两层结合方有意义。两个用户可能都有查询权限，但未必允许查询相同的表。实际上，该模型能支撑常见生产场景：

1. 可视化工具仅能读取报表数据
2. 采集服务只能写入指定的几张表
3. 团队账号能访问某个数据库，但无法访问另一个

ACL支持不同粒度：可开放某个数据库所有表，可精确授权单张表，也可用正则表达式匹配，例如mem_.*匹配所有以mem_开头的表。小团队可简单运用模型，大规模部署亦有充足演进空间。

因此，内置用户管理不仅解决登录问题：它确保每个账号仅能触达应触达的数据，由数据库在日常读、写和schema操作中强制执行权限。

日常管理

内置用户管理的设计目标是让运维真正好用，而非仅仅“技术上可行”。

启用后，GreptimeDB企业版提供内置HTTP API用于用户管理，无需重启服务器即可动态管理用户。Enterprise Dashboard也让这些操作变得简单：

1. 查看用户列表
2. 创建新用户
3. 更新权限
4. 编辑访问规则
5. 删除不再需要的用户

初始配置之后，无需再手工编辑配置文件。注意只有拥有admin权限的账号才能看到用户管理菜单，且内置的admin用户不能通过API删除。

适用场景

若需要以下能力，内置用户管理将非常合适：

1. 由数据库自身管理的持久化用户账号
2. 覆盖常见场景的基于角色的访问控制
3. 更精细地控制用户能访问哪些数据库或表
4. 通过API和UI完成的内置运维流程

对于希望获得生产级访问控制、又不想一开始就依赖外部身份系统的团队来说，它尤其合适。

写在最后

GreptimeDB企业版内置用户管理有效弥合了“简单初始凭证”与“完整生产级访问控制”之间的鸿沟。通过数据库内部创建用户、分配角色、限制访问范围并长期管理，团队从第一天起就能轻松遵循最小权限原则，实现安全高效的生产运维。