使用指南：GreptimeDB 用户读写权限控制

多用户环境下，数据安全的第一道防线是权限隔离。采集端只需写入能力，仪表盘只需读取能力——给多了是隐患，给少了影响业务。

GreptimeDB 1.0 beta1 引入了细粒度的读写权限控制。通过简单的配置文件，你可以为每个用户指定 readonly、writeonly 或 readwrite 权限，实现最小权限原则。

权限模式概览

GreptimeDB 支持三种权限模式：

模式	缩写	允许的操作	典型场景
`readwrite`	`rw`	读取 + 写入	管理员、开发环境
`readonly`	`ro`	仅读取	仪表盘、报表系统、只读副本
`writeonly`	`wo`	仅写入	数据采集器、IoT 设备、日志收集

未指定权限模式的用户默认拥有 readwrite 权限，与此前版本行为一致。

支持的协议

权限控制覆盖所有数据访问协议。读取操作包括 SQL 查询（MySQL/PostgreSQL 协议）、PromQL 查询、Prometheus Remote Read 和 Log Query；写入操作包括 SQL INSERT/DELETE、Prometheus Remote Write、InfluxDB Line Protocol、OpenTelemetry (OTLP)、OpenTSDB 和 Log 写入。

配置文件格式

用户凭证存储在一个文本文件中（建议 properties 为后缀），每行定义一个用户。

基本格式

最简形式只需用户名和密码，用 = 分隔：

text

admin=admin_password
alice=alice_password

这两个用户默认获得 readwrite 权限。

带权限模式的格式

在用户名后用冒号 : 附加权限模式：

text

username:permission_mode=password

权限模式支持多种写法（不区分大小写）：

权限	支持的写法
读写	`rw`, `readwrite`, `read_write`
只读	`ro`, `readonly`, `read_only`
只写	`wo`, `writeonly`, `write_only`

完整示例：

text

# 管理员账号
admin:readwrite=admin_secret

# 仪表盘账号 - 只读
grafana:readonly=grafana_pwd
dashboard:ro=dashboard_pwd

# 采集器账号 - 只写
telegraf:writeonly=telegraf_pwd
collector:wo=collector_pwd

# 旧格式 - 默认 readwrite
legacy_user=legacy_pwd

配置文件支持 # 开头的注释行、空行（会被忽略），以及密码中的特殊字符（如 p@ssw0rd!123）。

启动服务

Standalone 模式

使用 --user-provider 参数指定用户文件：

bash

./greptime standalone start \
    --user-provider=static_user_provider:file:/path/to/users.properties

💡 小提示:

文件路径必须是绝对路径，或相对于启动命令执行所在目录的相对路径
如果是在 Docker 容器环境中，确保挂载包含 users.properties 的文件或目录进入容器。

也可以直接在命令行配置用户（安全隐患，仅适合快速测试）：

bash

./greptime standalone start \
    --user-provider=static_user_provider:cmd:admin:rw=admin_pwd,grafana:ro=grafana_pwd

启动后，所有用户凭证加载到内存。连接时使用对应的用户名和密码：

bash

# MySQL 协议
mysql -h 127.0.0.1 -P 4002 -u grafana -pgrafana_pwd

# PostgreSQL 协议
psql -h 127.0.0.1 -p 4003 -U grafana -W

权限验证

只读用户尝试通过 Prometheus Remote Write 写入数据时，会收到权限错误：

yaml

# Prometheus 配置使用 grafana (readonly) 账号
remote_write:
  - url: http://localhost:4000/v1/prometheus/write?db=public
    basic_auth:
      username: grafana
      password: grafana_pwd

text

# Prometheus 日志报错
err="server returned HTTP status 403 Forbidden: {\"error\":\"User is not authorized to perform this action\"}"

只写用户尝试查询时同样被拒绝：

sql

-- 以 telegraf (writeonly) 用户登录
mysql> SELECT * FROM metrics;
ERROR 1045 (28000): User is not authorized to perform this action

动态加载用户

static_user_provider 有一个限制：用户文件在启动时一次性加载，运行期间修改不会生效。生产环境中，你可能需要在不重启服务的情况下添加或移除用户。

watch_file_user_provider 解决了这个问题，它会监控文件变化并自动重新加载：

bash

./greptime standalone start \
    --user-provider=watch_file_user_provider:/path/to/users.properties

主要特性：

文件格式与 static_user_provider 完全相同
检测到修改后自动重载（通常在数秒内）
若新文件内容无效（如格式错误），保持上一次的有效配置
支持热添加、删除、修改用户及其权限

这在需要频繁调整访问控制的场景下很实用，比如临时授予调试权限、轮换服务账号密码。

Kubernetes 部署

使用 Helm Chart 部署时，在 values.yaml 中配置认证：

yaml

auth:
  enabled: true
  users:
    - username: admin
      password: admin_secret
      permission: readwrite
    - username: grafana
      password: grafana_pwd
      permission: readonly
    - username: telegraf
      password: telegraf_pwd
      permission: writeonly

更多 Kubernetes 配置细节，参考 Helm Chart 配置文档。

💡 小提示: Helm Chart 请使用 GreptimeDB 最新版本。

典型场景

下面列举几个常见的权限配置场景。

监控数据采集

Prometheus、Telegraf、OpenTelemetry Collector 等采集器只需写入权限。为它们创建只写账号，即使凭证泄露，攻击者也无法读取历史数据：

text

prometheus:writeonly=prom_secret_2024
telegraf:wo=tele_secret_2024
otel:wo=otel_secret_2024

仪表盘与报表

Grafana、Superset、自建报表系统只需读取权限。只读账号可以防止误操作删除或修改数据：

text

grafana:readonly=grafana_pwd
superset:ro=superset_pwd
report_system:ro=report_pwd

开发与生产隔离

开发环境的账号不应有生产数据的写入权限：

text

prod_collector:writeonly=prod_write_secret
prod_dashboard:readonly=prod_read_secret
dev_alice:readonly=alice_dev_pwd
dev_bob:readonly=bob_dev_pwd

多租户隔离

结合数据库级别的隔离，不同团队使用不同账号：

text

team_a_writer:writeonly=team_a_write
team_a_reader:readonly=team_a_read
team_b_writer:writeonly=team_b_write
team_b_reader:readonly=team_b_read

提示：当前版本的权限控制是全局的，不支持表级或数据库级的细粒度授权。如需更精细的隔离，建议使用独立的 GreptimeDB 实例或 GreptimeCloud 的多租户功能。

安全建议

1. 遵循最小权限原则。 每个服务账号只授予必需的权限。采集器用 writeonly，仪表盘用 readonly，只有管理操作才需要 readwrite。

2. 定期轮换密码。 使用 watch_file_user_provider 可以在不停机的情况下更新密码。建议建立定期轮换机制。

3. 保护凭证文件。 用户文件应设置严格的文件系统权限（如 chmod 600），避免非授权访问。

4. 使用强密码。 避免使用默认密码或弱密码。可以用 openssl rand -base64 32 生成随机密码。

5. 监控认证失败。 关注日志中的认证失败记录，及时发现暴力破解尝试。

快速上手

配置只需两步：

bash

# 1. 创建用户文件
cat > users.properties << EOF
admin:rw=admin_pwd
grafana:ro=grafana_pwd
collector:wo=collector_pwd
EOF

# 2. 启动服务
./greptime standalone start --user-provider=watch_file_user_provider:./users.properties

延伸阅读：

使用指南：GreptimeDB 用户读写权限控制

权限模式概览 ​

支持的协议 ​

配置文件格式 ​

基本格式 ​

带权限模式的格式 ​

启动服务 ​

Standalone 模式 ​

权限验证 ​

动态加载用户 ​

Kubernetes 部署 ​

典型场景 ​

监控数据采集 ​

仪表盘与报表 ​

开发与生产隔离 ​

多租户隔离 ​

安全建议 ​

快速上手 ​

加入我们的社区

权限模式概览

支持的协议

配置文件格式

基本格式

带权限模式的格式

启动服务

Standalone 模式

权限验证

动态加载用户

Kubernetes 部署

典型场景

监控数据采集

仪表盘与报表

开发与生产隔离

多租户隔离

安全建议

快速上手