一个权限平台，能否真正管理企业中的数据库、搜索引擎、消息队列和大数据组件？
这正是 GrantForge 一直在尝试解决的问题。
在实际的软件系统中，权限管理远比用户、角色、菜单和按钮复杂。
一家企业可能同时运行着 MySQL、PostgreSQL、ClickHouse、OpenSearch、Kafka、HDFS 等多个系统。
这些系统通常拥有各自的账号、角色、授权规则和访问控制机制。
对于开发人员而言，这意味着需要学习并维护多套权限模型；对于安全和运维团队而言，则意味着权限配置分散、策略难以统一、访问审计复杂。
如果能够在一个平台中定义和管理权限，再将这些策略落实到不同的数据系统中，会怎么样？
这就是开源项目 GrantForge 的目标。
今天，我们带来了 GrantForge v2026.3.0。
本次版本包含 32 个提交，重点新增了 PostgreSQL、ClickHouse、OpenSearch、Apache Solr 和 Apache Pulsar 五大系统的服务插件与 Agent，并继续完善策略引擎和 Agent 核心能力。
一、从 8 种到 13 种，GrantForge 的外部系统生态继续扩展
如果你第一次接触 GrantForge，可以将它理解为一个面向现代应用与数据基础设施的统一权限管理平台。
传统 RBAC 系统通常关注：
-
用户拥有哪些角色？
-
角色可以访问哪些菜单和 API？
-
谁有权操作某个业务功能？
而 GrantForge 希望进一步回答：
-
用户是否可以查询某张数据库表？
-
某个账号能看到哪些数据行？
-
敏感字段是否需要脱敏？
-
用户是否有权访问特定消息主题？
-
对外部系统的访问能否集中授权和审计？
在此前的版本中，GrantForge 已经逐步接入 HDFS、ZooKeeper、MySQL、Hive、Kafka、HBase、Trino 和 YARN。
而在 2026.3.0 中，我们一次性增加了五种新的系统类型。
|
新增系统 |
主要应用领域 |
|---|---|
|
PostgreSQL |
关系型数据库 |
|
ClickHouse |
OLAP 实时分析数据库 |
|
OpenSearch |
搜索与分析引擎 |
|
Apache Solr |
企业搜索引擎 |
|
Apache Pulsar |
分布式消息与流处理 |
至此，GrantForge 已拥有 13 种外部系统服务插件。
这不只是插件数量的增加，更意味着统一权限模型正在覆盖更多真实的数据基础设施。
二、PostgreSQL：让数据库权限进入统一治理体系
PostgreSQL 是广泛使用的开源关系型数据库，其原生权限体系支持角色、数据库对象授权和行级安全策略（Row-Level Security）。
但在复杂的企业环境中，数据库权限经常由 DBA 单独管理，而业务系统的用户与角色又维护在另外一套平台中。
两套权限模型之间缺少统一的管理入口。
2026.3.0 正式增加 PostgreSQL 服务插件与 Agent。
此次接入的重要特点，是利用 PostgreSQL 自身的权限机制，而不是简单地在业务应用外面增加一层权限判断。
GrantForge 可以通过对应的服务插件管理资源和访问策略，并通过 Agent 将相关权限同步到 PostgreSQL 原生的角色、对象权限和行级安全策略中。
例如，一家企业希望：
-
数据分析人员只能读取指定业务表。
-
不同部门只能查询各自负责的数据。
-
运维人员根据职责获得不同的数据库访问权限。
-
权限调整由统一平台管理。
过去，这些需求可能需要手动维护多条数据库授权语句和行级安全规则。
引入 GrantForge 后，可以把权限策略管理集中到一个平台，再由 PostgreSQL 的原生权限能力执行相应约束。
核心价值：减少业务权限与数据库授权之间的割裂，使数据库权限更容易统一管理。
三、ClickHouse：为实时分析场景引入统一权限管理
随着实时数仓、日志分析、用户行为分析等场景不断增多，ClickHouse 已成为不少数据平台的重要组件。
但是，分析数据库同样存在权限问题。
例如：
一家企业将来自多个业务部门的日志、订单和运营数据汇聚到 ClickHouse 中。
数据分析师需要访问分析数据，但不意味着所有分析师都应该获得同样的数据访问范围。
如果只是开放整个数据库的查询权限，很容易造成权限过大。
在 2026.3.0 中，GrantForge 新增：
-
ClickHouse 服务类型插件
-
ClickHouse Agent
-
相关使用文档和接入说明
ClickHouse Agent 采用与 PostgreSQL 类似的原生权限同步思路，使 ClickHouse 内部的角色与行策略能够跟随 GrantForge 的权限配置保持一致。
这让 ClickHouse 不再只是一个单独管理权限的分析数据库，而是可以加入整个组织的统一数据权限治理体系。
对于使用 ClickHouse 构建实时分析平台的团队来说，最大的价值在于：
数据权限可以从平台层面统一管理，再交给 ClickHouse 自身的机制执行。
需要说明的是，具体能够落实的权限范围仍取决于 ClickHouse 的原生安全能力和 GrantForge 对应 Agent 的实现范围。
四、OpenSearch：搜索结果也需要权限控制
很多开发人员在谈论权限时，首先想到的是数据库中的表和记录。
但实际上，搜索系统同样可能包含大量敏感信息。
例如：
-
企业内部的文档搜索
-
用户行为检索
-
安全日志查询
-
业务数据全文检索
-
多租户搜索服务
假设一个企业将多个部门的文档索引到 OpenSearch。
普通员工在执行搜索时，理应只能获取自己有权访问的文档，而不应该因为拥有搜索接口的调用权限，就能看到全部索引内容。
这也是搜索引擎权限治理与普通 API 权限控制之间的重要区别。
GrantForge 2026.3.0 新增 OpenSearch 服务插件与 Agent。
这一接入面向 OpenSearch Security Plugin 的原生权限能力，涉及：
-
角色及其访问权限的同步
-
文档级安全（Document-Level Security）
-
字段级安全（Field-Level Security）
-
敏感字段掩码策略
通过这些能力，可以将统一平台中的授权策略与搜索引擎的原生访问控制结合起来。
例如，同一个搜索索引包含不同部门的数据，可以依据用户权限限制能够返回的文档；对于敏感字段，也可以按照相应规则限制可见范围。
这意味着 GrantForge 管理的不再只是用户能否调用搜索 API，还可以进一步涉及搜索数据本身的访问范围。
对于构建企业搜索平台、日志检索平台和数据服务平台的团队而言，这是非常有价值的一步。
五、Apache Solr：将权限控制延伸到搜索节点
除了 OpenSearch，本次版本还加入了 Apache Solr。
Solr 同样是成熟的开源搜索平台，广泛应用于全文检索、文档搜索和企业级搜索服务。
GrantForge 为 Solr 提供了服务类型插件，以及部署于 Solr 节点中的授权 Agent。
相比单纯在外围应用中检查权限，这种方式可以让访问控制更接近真正提供搜索服务的节点。
例如，企业内部有多个系统同时使用 Solr：
-
管理后台查询搜索数据
-
内部服务直接调用 Solr API
-
业务应用访问不同的集合和资源
如果仅依赖某一个应用的接口权限控制，其他访问路径可能需要重复实现相同的授权逻辑。
引入节点级权限执行机制后，便可以围绕 Solr 自身的请求处理路径落实访问控制。
本次还将 Solr Agent 的构建基线调整到 Solr 9.10.1，并补充了对应的接入文档。
需要强调的是，Solr Agent 的具体保护资源与执行范围，应以对应版本的插件及 Agent 文档为准。
六、Apache Pulsar：统一权限管理进入消息系统
在现代微服务和数据平台架构中，消息系统承担着大量异步通信与数据传输任务。
此前 GrantForge 已经支持 Apache Kafka。
而在 2026.3.0 中，我们进一步加入 Apache Pulsar。
Pulsar 使用 Topic 和 Namespace 等资源概念组织消息服务。
对于多租户或多业务团队而言，消息资源授权是一个非常重要的问题。
例如：
某个业务系统只应该访问自己负责的 Topic，而不应该因为能够连接消息集群，就具备操作其他业务主题的权限。
此次新增的 Pulsar 服务插件与 Broker 授权 Agent，使 GrantForge 可以进一步参与 Pulsar 的访问权限管理。
这一版本还针对 Pulsar 进行了两项修复：
第一，优化 Namespace 下 Topic 的资源发现处理。
修复特定资源查询情况下 Topic 结果未被正确保留的问题，提高资源识别的准确性。
第二，改善 Broker 连接失败的错误识别。
当连接被拒绝时，能够更加准确地报告 Broker 不可达问题，帮助运维人员更快定位连接故障。
从 Kafka 到 Pulsar，GrantForge 正在逐步完善消息基础设施的授权能力。
七、这次不只是新增插件，Agent 核心也在持续增强
如果只看新增的五个系统，可能会认为这次发布主要是在扩展兼容性。
实际上，Agent 核心与策略引擎的改进同样值得关注。
1. Agent 到底负责什么？
这里的 Agent 指的是权限执行组件，而不是大语言模型驱动的 AI Agent。
GrantForge 采用管理面与数据面分离的思路：
管理面（Management Plane）
负责统一管理用户、角色、资源、权限策略和访问审计。
数据面（Data Plane）
由部署在受保护系统内部或网络访问路径上的 Agent 执行相应的访问控制逻辑。
不同类型的系统，执行方式也可能不同。
例如：
-
MySQL 使用独立的网络代理。
-
Solr 采用节点授权插件。
-
Pulsar 通过 Broker 授权机制接入。
-
PostgreSQL、ClickHouse 和 OpenSearch 则更多利用各自的原生权限机制进行策略同步。
这些实现方式并不完全相同，但共享 GrantForge 的统一权限管理思路。
Agent 核心还提供签名策略快照、策略缓存和访问审计等基础能力，以支持外部系统在各自执行路径中落实权限。
2. 更完善的脱敏与行过滤策略接口
2026.3.0 对 Agent Core 进行了进一步增强。
新增能力包括：
-
向 Agent 暴露字段脱敏策略
-
向 Agent 暴露数据行过滤策略
-
提供命名用户相关信息
-
将策略集合的访问接口调整为只读视图
为什么这些改进重要？
因为不同的数据系统执行数据权限的方式不同。
有的数据库支持原生行级安全规则，有的系统需要通过授权插件执行访问控制，还有的系统需要在查询处理过程中实现数据过滤。
Agent Core 的价值，就是为这些不同的执行方式提供可以复用的基础能力。
同时，只读策略视图能够减少外部组件意外修改已获取策略数据的风险，有助于提升执行逻辑的稳定性。
统一管理不代表所有系统必须使用相同的技术手段，而是允许不同执行机制遵循统一的授权策略。
这是 GrantForge 插件与 Agent 架构的重要设计方向。
3. 策略引擎增强：进一步判断资源下级的权限约束
此次更新还增强了 Policy Engine。
对于层级资源，权限判断不仅需要考虑当前资源本身，还可能需要识别其下级资源是否存在更细粒度的权限限制。
例如：
一个用户可能拥有访问某个数据库的权限，但数据库下某些表仍受到额外限制。
同样，在文件系统、消息系统或搜索平台中，父级资源的可访问性也不必然意味着全部子资源拥有相同权限。
本次策略引擎增加了识别资源下级潜在权限约束的能力，为复杂资源层级的策略判断提供进一步支持。
八、稳定性、安全性与工程质量同步改进
除了新系统接入，2026.3.0 也对已有实现进行了针对性修复。
Agent 运行兼容性
OpenSearch Agent 将 SLF4J 依赖进行内部重定位，降低 Agent 与宿主运行环境之间的日志依赖冲突风险。
PostgreSQL 日志时间解析
修复 PostgreSQL 服务日志中时区缩写的解析问题，提高相关日志时间处理的兼容性。
Pulsar 资源发现与连接诊断
改进 Topic 查询处理，以及 Broker 连接被拒绝时的错误提示。
依赖安全
处理 npm 依赖安全扫描发现的相关安全公告问题，减少已知依赖风险。
自动化测试和发布流程
优化端到端测试中的服务类型选择流程，并改进 GitHub Release 标题生成方式，使发布版本展示更加一致。
与此同时，针对本次新增的五大系统，项目也同步补充了插件与 Agent 的使用文档。
我们希望 GrantForge 的每一项新能力不只是可以在源码中找到，还能够让开发者理解其用途、了解支持范围并尝试实际部署。
九、GrantForge 想解决的，不只是权限管理页面
从最初的用户、角色和功能权限管理，到现在逐步扩展数据库、大数据组件、搜索引擎和消息系统，GrantForge 正在形成一套更完整的权限治理架构。
我们希望让开发者能够在一个平台中处理两类问题：
第一，谁可以做什么？
例如：
-
谁有权登录系统？
-
谁能调用业务 API？
-
哪些角色可以执行特定操作？
-
哪些用户可以访问特定数据资源？
第二，谁可以看到哪些数据？
例如：
-
是否允许读取某张数据库表？
-
哪些数据行对当前用户可见？
-
哪些敏感字段需要受到保护？
-
不同用户能否访问相同的搜索结果？
-
哪些消息资源允许特定业务访问？
在传统架构中，这些问题可能分别交给业务后端、数据库管理员、数据平台、安全团队和运维人员处理。
而 GrantForge 的方向，是通过统一权限模型、可扩展的服务插件和不同形态的执行 Agent，将这些分散的管理需求连接起来。
当然，统一权限治理不是简单安装一个平台就能完成。
各类数据系统的原生权限能力、接入方式、认证机制和执行粒度都存在差异。
GrantForge 也会明确不同 Agent 的支持范围，而不是假设所有系统都能以完全相同的方式执行每一种权限策略。
但随着支持系统不断增加，我们距离统一治理复杂数据基础设施的目标又迈进了一步。
十、开源，让更多开发者参与进来
GrantForge 是基于 MIT License 开源的统一权限管理平台。
项目采用 Spring Boot、Spring Security、Vue 3 等技术，并通过插件与 Agent 扩展外部系统的权限治理能力。
我们希望它不仅能用于普通的后台管理系统，也能为企业数据平台、微服务系统和复杂数据基础设施提供可扩展的授权基础。
如果你正在面临以下问题：
-
多套业务系统的权限重复建设
-
数据库权限与业务身份管理割裂
-
数据行和字段权限难以统一
-
搜索和消息系统需要独立维护权限
-
外部数据系统访问审计分散
-
希望构建可扩展、可自主部署的权限治理平台
欢迎了解 GrantForge，也欢迎参与社区交流和贡献。
项目地址
https://github.com/devlive-community/grantforge
官方文档
https://grantforge.devlive.org/
完整版本变更
https://github.com/devlive-community/grantforge/compare/v2026.2.0...v2026.3.0
写在最后
从 2026.1.0 的 HDFS、ZooKeeper、MySQL，到 2026.2.0 的 Hive、Kafka、HBase、Trino、YARN，再到本次 2026.3.0 新增的 PostgreSQL、ClickHouse、OpenSearch、Solr 与 Pulsar。
GrantForge 正在逐渐从一个应用权限管理平台，走向覆盖更多数据基础设施的统一权限治理平台。
我们的目标不是重新发明每一种数据库或消息系统的权限机制，而是让这些原本分散的机制能够更容易被统一管理、执行与审计。
如果这个项目对你有帮助，欢迎在 GitHub 为 GrantForge 点一颗 Star。
每一个 Issue、PR 和实际使用反馈，都会帮助这个开源项目继续完善。
GrantForge —— 让权限统一管理，让访问有据可依。