StarRocks 4.0：基于 Apache Iceberg 的 Catalog 中心化访问控制

导读： StarRocks 4.0 已正式发布！这一版本带来了多项关键升级。接下来，我们将以每周一篇的节奏，逐一解析 4.0 的核心新特性。 在多引擎协同访问同一数据湖的场景下，如何实现安全、统一且可审计的权限管理，是 Lakehouse 架构演进中的一项关键挑战。StarRocks 4.0 联合 Apache Iceberg，借助 REST Catalog 的统一治理能力与 JWT 身份认证、临时凭证机制（Vended Credential），为多引擎湖仓架构提供了一种全新的安全访问方式。 本文将介绍这一模型的核心原理，以及在 StarRocks 4.0 中的实践落地。

Apache Iceberg 提供了一种开放、通用的表格式，任何计算引擎都可以直接使用。

但这种灵活性也带来了新的挑战：当每个引擎都需要访问相同数据时，如何确保访问控制既统一又可审计？

传统的数据仓库依赖“超级用户”与长期凭证的做法显然行不通——湖仓架构需要的是一种全新的访问控制模型。

传统数仓安全模型的局限

在传统数据仓库中，安全体系以“引擎”为中心，由单一系统负责所有环节——身份认证、权限授权、查询执行以及存储访问：

• 用户登录到仓库引擎，通常通过外部身份提供商（IdP）进行身份验证。
• 引擎通过自身的授权系统，或对接外部策略管理器（如 Apache Ranger）来实现统一治理。然而，查询执行依然依赖一个高权限的“超级账户”，存在安全隐患；
• 在后台，引擎掌握着 Catalog 与底层存储的访问特权，并对最终用户屏蔽了底层凭证。

这种以引擎为中心的安全模式在 Apache Iceberg 体系中并不适用。Iceberg 支持多个计算引擎同时读写同一张表，如果每个引擎都各自持有高权限凭证并独立管理访问控制，问题便接踵而至：

• 权限蔓延：每个引擎都需要超级账号或长期存储密钥，泄露风险成倍增加；
• 策略不一致：不同引擎执行的访问规则各不相同，难以形成统一的安全标准；
• 审计割裂：操作日志分散在各个引擎，安全团队无法获得完整的用户行为视图。

因此，传统引擎中心化的安全模型，已经无法满足开放、多引擎湖仓架构的安全与治理需求。

以 Catalog 为核心的安全与治理体系

在 Iceberg 架构中，REST Catalog 是表元数据的单一事实来源（Source of Truth）。基于这一前提，安全与治理也应围绕 Catalog 构建统一的控制平面：

各计算引擎不再持有高权限的超级密钥，而是以真实用户身份访问 Catalog，由 Catalog 统一负责以下职能：

• 权限控制（Authorization）：在数据库、表乃至列级别执行精细化访问策略；
• 凭证管理（Credential Vending）：按需签发短期、最小权限的访问令牌，确保数据安全；
• 操作审计（Auditing）：集中记录所有操作行为，无论查询来自哪个引擎。

在建立这一基础之后，接下来要关注的是——这种模型在实践中如何运作：从引擎到 Catalog，再到存储，各环节如何协同。

参考架构：StarRocks 4.0 在 Apache Iceberg 上的实践

在实际落地中，这种以 Catalog 为核心的安全模型可归纳为一个简洁而高效的流程：引擎负责用户认证，Catalog 负责权限判断，而底层存储通过短期凭证访问，摆脱长期密钥的风险。

StarRocks 4.0 引入了 JWT (JSON Web Token) 身份透传功能，并支持通过 Iceberg REST Session Catalog 进行凭证发放，这一架构实现了完整的端到端落地。

具体流程如下：

1. 用户认证 —— 用户登录 StarRocks，由企业 IdP 完成身份校验；
2. 身份传递 —— StarRocks 将用户的 JWT 身份令牌透传至 Iceberg REST Session Catalog，使查询始终以真实用户身份执行；
3. 权限校验 —— Catalog 基于该身份对数据库、表和列级权限进行精细化判定；
4. 签发短期凭证 —— 若访问被批准，Catalog 为数据访问生成临时存储令牌，而非长期密钥；
5. 查询与集中审计 —— StarRocks 使用短期凭证执行查询，Catalog 同步记录真实用户的访问操作，实现统一的审计追踪。

这一流程彻底消除了引擎层的超级账号依赖，将安全控制权回归 Catalog，使访问策略在所有引擎间保持一致，并确保审计链路统一、可追溯。

如何在 StarRocks 4.0 中启用以 Catalog 为核心的访问控制

要在 StarRocks 4.0 中启用 Catalog 中心化访问控制，只需完成以下几个关键步骤：

配置 JWT 认证

在引擎端启用并配置企业 IdP 签发的 JWT 令牌接入与透传，使用户的真实身份能够传递到 Catalog。

创建 Iceberg REST Session Catalog

将 Catalog 配置为 security=jwt，并启用凭证签发（vended credentials），即可将授权和存储访问从引擎侧转移到 Catalog 统一管理。

CREATE EXTERNAL CATALOG iceberg_rest_catalog
PROPERTIES (
"iceberg.catalog.type" = "rest",
"iceberg.catalog.uri" = "https://<rest_server_api_endpoint>",
"iceberg.catalog.security" = "jwt",
"iceberg.catalog.warehouse" = "<s3|oss|hdfs_warehouse_path_or_identifier>",
"iceberg.catalog.vended-credentials-enabled" = "true"
);

在引擎中授予 Catalog 使用权限

在引擎中仅保留最小权限（Catalog 使用权限），将精细化访问控制下放到 Catalog 后端，可使用原生策略或对接 Apache Ranger 等策略系统。

向所有用户开放：

GRANT USAGE ON CATALOG iceberg_rest_catalog TO ROLE public;

——或选择——

基于角色的访问控制（Role-Scoped）

CREATE ROLE data_analyst;
GRANT data_analyst TO EXTERNAL GROUP <your_idp_group>;
GRANT USAGE ON CATALOG iceberg_rest_catalog TO ROLE data_analyst;

将访问控制全面托管给 Catalog

在 StarRocks 侧关闭访问控制，由 Catalog 集中执行所有授权，避免重复配置并确保跨引擎策略一致。

ALTER CATALOG iceberg_rest_catalog
SET PROPERTIES (
"catalog.access.control" = "allowall"
);

以 Catalog 为核心的安全实践

当身份验证、权限控制与凭证签发都交由 Catalog 统一管理后，湖仓终于具备了一套与数据格式同样一致、可审计的安全体系。

借助 StarRocks 4.0 与 Iceberg REST Session Catalog，这一架构已经从概念走向落地，从根本上消除了超级账号与长期密钥带来的安全风险。

如想进一步学习与交流，欢迎添加小助手，加入 StarRocks 社区群，与更多开发者共同探索交流。