Static User Provider
GreptimeDB 通过 static_user_provider 提供用户名和密码认证,在启动时从文件或命令行参数加载凭证。watch_file_user_provider 使用相同的文件格式,并在文件变更时重新加载凭证。
单机模式
GreptimeDB 从配置文件中读取用户配置,每行定义一个用户及其密码和可选的权限模式。
基本配置
基本格式使用 = 作为用户名和密码之间的分隔符:
greptime_user=greptime_pwd
alice=aaa
bob=bbb
以这种方式配置的用户默认拥有读写权限。文件解析规则如下:
- 每行的首尾空白会被移除,空行和以
#开头的行会被忽略。 - 每条凭证必须恰好包含一个
=。明文密码不能包含=,添加plain:前缀也不能绕过此限制。此类密码需要以支持的哈希 verifier 格式存储。 - 用户名和密码中位于
=两侧的空白不会被移除,不要在分隔符两侧添加空格。 - 同一用户名出现多 次时,最后一条有效记录生效。
- 格式错误的记录会被跳过。文件必须存在且至少包含一条有效凭证,否则 provider 初始化失败。
- 读取错误(包括无效 UTF-8)会终止后续解析,错误发生前读到的有效凭证仍可能被加载。
格式错误的记录和读取错误会在服务端日志中产生告警。
对于 MySQL 和 PostgreSQL 连接,用户名 * 保留用于 Bearer Token 认证。static_user_provider 和 watch_file_user_provider 不支持 Bearer Token,因此不能使用 * 作为通过密码认证的 SQL 用户名。
权限模式
可通过可选的权限模式控制读写访问,格式为:
username:permission_mode=password
权限模式不区分大小写:
rw、readwrite或read_write- 读写权限(未指定时的默认值)ro、readonly或read_only- 只读权限wo、writeonly或write_only- 只写权限
无法识别的权限模式会使该记录无效:文件 provider 会跳过该记录,static_user_provider:cmd 则会初始化失败。
这些权限模式不限定到单个数据库或表。
混合权限模式的配置示例:
admin=admin_pwd
alice:readonly=aaa
bob:writeonly=bbb
viewer:ro=viewer_pwd
editor:rw=editor_pwd
在此配置中:
admin拥有读写权限(默认)alice拥有只读权限bob拥有只写权限viewer拥有只读权限editor明确设置了读写权限
密码格式
从 v1.1 起,密码支持明文和哈希 verifier,格式如下:
plain:<password>— 明文。未指定前缀时的默认格式。pbkdf2_sha256:<iterations>:<hex_salt>:<hex_hash>— 以 PBKDF2-SHA256 哈希形式存储。mysql_native_password:<hex_sha1_sha1_password>— 用于 MySQLmysql_native_password认证的哈希 verifier。pg_scram_sha256:<iterations>:<hex_salt>:<hex_stored_key>:<hex_server_key>— 用于 PostgreSQL SASL 认证的 SCRAM-SHA-256 verifier。从 v1.2 起支持。
以下哈希 verifier 示例使用密码 password,需要盐值的格式使用 salt:
admin=plain:admin_pwd
alice=pbkdf2_sha256:4096:73616c74:c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
bob=mysql_native_password:2470c0c06dee42fd1618bb99005adca2ec9d1e19
carol=pg_scram_sha256:4096:73616c74:945e1c466fc9932efadc23781edc5d1e78d5e10f005933652af1a6105154f084:b9bf0e811b1fb6793671c0cc3adedf7c75cd72291191092ad65878c5a02aad2c
权限模式可与 verifier 格式组合使用,verifier 写在 = 之后:
alice:readonly=pbkdf2_sha256:4096:73616c74:c5e478d59288c841aa530db6845c4c8d962893a001ce4e11a4963873aa98134a
协议兼容性
协议支持情况取决于 verifier 格式和 provider 选择的认证方法:
| Verifier | HTTP/gRPC 用户名和密码 | PostgreSQL SCRAM-SHA-256 | PostgreSQL cleartext | MySQL mysql_native_password |
|---|---|---|---|---|
plain:<password>(或旧式 user=password) | 是 | 是 | 是 | 是 |
pbkdf2_sha256:... | 是 | 否 | 是 | 否 |
mysql_native_password:... | 否 | 否 | 否 | 是 |
pg_scram_sha256:... | 是 | 是 | 是 | 否 |
static_user_provider 和 watch_file_user_provider 协商的 MySQL 认证方法是 mysql_native_password,不提供 mysql_clear_password。使用 pbkdf2_sha256 或 pg_scram_sha256 的用户无法通过这两个 provider 进行 MySQL 认证。启用 TLS 或客户端的明文认证插件不会改变服务端选择的认证方法。
哈希 verifier 用于保护存储的凭证,不会加密网络流量。生产环境应启用 TLS,尤其是使用 HTTP/gRPC 用户名和密码认证或 PostgreSQL 明文认证时。
密码按前缀解析。如果旧式明文密码恰好以 plain:、pbkdf2_sha256:、mysql_native_password: 或 pg_scram_sha256: 开头,其含义会发生变化。使用 plain: 前缀保留字面值。例如,若要保留字面密码 plain:secret,应配置为 user=plain:plain:secret。
PostgreSQL SCRAM-SHA-256
PostgreSQL 客户端使用 SCRAM-SHA-256 认证时,不发送明文密码。
只有所有已配置用户都使用明文密码(带或不带 plain: 前缀)或 pg_scram_sha256: verifier 时,GreptimeDB 才会选择 SCRAM-SHA-256。这两种格式可以混用。
使用 SCRAM-SHA-256 时,服务端也会向未知用户发送认证挑战。客户端提交 proof 后,服务端返回与密码错误相同的认证失败结果。
只要存在一条 pbkdf2_sha256: 或 mysql_native_password: 记录,该 provider 的所有用户都会使用 PostgreSQL 明文认证。使用 mysql_native_password: verifier 的用户也无法通过回退后的明文认证,因为该 verifier 不能校验明文密码。
加载的凭证导致 PostgreSQL SCRAM 认证不可用时,服务端会记录告警。
不支持 channel binding(SCRAM-SHA-256-PLUS)。
将所有用户配置为支持 SCRAM 的凭证后,可使用 libpq 或 psql 16 及以上版本验证认证方法:
psql "host=127.0.0.1 port=4003 user=carol dbname=public require_auth=scram-sha-256"
如果实例使用明文认证,命令会报错 server requested a cleartext password。