ClickStack RBAC 重磅发布！精细化权限管理，企业级安全升级

Meetup活动

ClickHouse 上海第3届 Meetup 火热报名中，详见文末海报！

我们发布了 ClickStack 推出以来最受期待的功能之一：面向托管型 ClickStack 的基于角色的访问控制 (RBAC)。ClickStack RBAC 允许团队根据角色定义权限，并控制谁可以访问特定的资源，例如仪表盘、保存的搜索和笔记本。访问权限可以从广义层面授予，也可以细化到单个资源，同时还能管理谁可以在整个平台中创建、修改或管理关键功能。

这不仅确保了平台具备企业级就绪能力，也为更高级的访问控制奠定了基础，未来计划通过更新来扩展 RBAC 功能，例如行级访问控制。

RBAC 的基础

在引入 RBAC 之前，所有 ClickStack 用户都属于同一组，并在整个应用程序中共享相同的权限，无法在单个实例内区分用户或团队之间的访问权限。

为了实现任何程度的隔离，团队不得不依赖独立的 HyperDX 实例。每个实例都需配置自己的连接凭据和数据源，从而在环境层面而非产品内部实现访问隔离。尽管这提供了一种限制底层数据访问的变通方案，但其代价是重复设置和增加运维开销。

这种模型无法满足实际团队的需求。它无法控制对特定仪表盘的访问、强制只读权限，或限制对仪表盘创建或笔记本等功能的访问。显然，需要一种更灵活、更集中的访问控制方法。

基于组的访问控制模型

根据用户的反馈，ClickStack 显然需要一种更灵活、基于组的访问控制方法。RBAC 的核心在于引入了定义角色并将用户分配给这些角色的能力，每个角色管理平台中关键资源的访问权限。这些资源包括仪表盘、保存的搜索、数据源、告警、Webhook 和笔记本。

对于每种资源类型，角色可以被赋予三种访问级别之一：无访问权限、读取权限或管理权限。该模型覆盖了大多数使用场景，允许团队控制谁可以查看数据、谁可以进行更改以及谁拥有完全控制权。管理权限允许用户创建、编辑和删除资源，而读取权限则确保了可见性，同时避免了修改风险。

除了资源访问，RBAC（基于角色的访问控制）还在角色层面引入了管理控制功能。团队可以定义哪些角色被允许查看团队成员及其分配的角色，同时将管理用户和权限等敏感操作仅限于管理员执行。这确保了数据消费者与访问管理责任人之间职责的明确分离。

细粒度控制

虽然在资源层面（resource level）分配无、只读或管理权限已提供了坚实的基础，但许多团队需要更精细的控制。为此，ClickStack 中的 RBAC 支持细粒度访问规则，允许将权限限定于特定资源，而非统一应用。

默认情况下，每种资源类型都使用一个适用于所有资源的单一访问策略。切换到细粒度控制后，角色可以定义多个访问规则，每个规则独立评估。如果资源与任何规则匹配，则拥有相应角色的用户即可访问该资源；而与规则不匹配的资源则保持不可访问。这使得我们能够选择性地仅向特定团队或角色暴露其相关的资产。

访问规则可以根据资源属性（例如名称、ID 或标签）进行定义。例如，在图中，该角色被授予了对所有包含“errors”一词的已保存搜索的只读权限，以及对所有带有特定团队标签的搜索的管理权限。每条规则都明确了匹配条件和访问级别，从而实现了灵活且有针对性的权限模型。同样的细粒度过滤机制也可以应用于仪表板、数据源和笔记本。

有关支持的过滤条件的完整说明，请参阅 RBAC 文档（https://clickhouse.com/docs/use-cases/observability/clickstack/rbac）。

集成 ClickHouse Cloud

ClickStack 中的 RBAC 旨在与 ClickHouse Cloud 无缝集成，确保整个平台的用户管理和权限保持一致。用户在 ClickHouse Cloud 层面进行管理，他们会被邀请加入组织，并通过 Cloud 控制台分配基线访问权限。

一旦用户作为成员获得 ClickHouse Cloud 的访问权限，他们就会出现在 ClickStack 团队设置的用户界面（UI）中，可以在此分配角色。用户必须至少拥有 SQL 控制台只读访问权限才能使用 ClickStack，而完整的管理员则需要 SQL 控制台的管理员访问权限，这对于启用警报等功能是必不可少的。

这种模式将用户生命周期管理集中在 ClickHouse Cloud 中进行，而 ClickStack 则专注于管理应用程序内部的基于角色的权限。实际上，这意味着团队在云层面管理用户身份及其访问权限，然后利用 ClickStack 角色来控制该用户在可观测性工作流中的可见内容和可执行操作。

为了使这种体验尽可能无缝，新用户会被分配一个默认角色——这可以在 ClickStack 团队设置中配置。

加强控制力

本次发布为 ClickStack 中的 RBAC (Role-Based Access Control) 奠定了基础，但这只是第一步。虽然它引入了对功能和资源的结构化控制，但显然，访问策略需要变得更加细粒度，并需从应用层扩展到数据本身。

目前，在数据层面限制访问通常需要配置 ClickHouse 中的权限，并将其映射到特定的连接和数据源 (source)。在实践中，ClickStack 中的数据源与 ClickHouse 中的表相对应，通过上述的细粒度权限，可以控制哪些角色能够查看或使用这些数据源，从而限制访问。这种方式对于需要在表级别进行访问限制的场景非常适用。

然而，行级访问则会引入额外的复杂性。在这种情况下，不同的角色可以访问每个数据源中的不同行，这通常通过 SQL 过滤条件来定义，例如“只允许访问支付服务的日志”。

目前，为了实现这一点，管理员必须通过 ClickHouse 自身来管理访问权限，具体做法是为单个 SQL 控制台用户分配角色。这些角色遵循 sql-console-role:<email> 的命名模式，并定义了控制每个用户访问特定数据集的权限。这些 SQL 控制台用户会在 ClickStack 中显示，然后可以像前文所述那样，将他们分配给一个 ClickStack 角色。

尽管此方法提供了一定程度的控制，但也引入了一个分层管理模型：角色既在 ClickHouse 中定义，又在 ClickStack 中单独定义，这要求管理员在两个平台之间协调权限。随着用户和角色数量的增长，这种模式很快就变得难以管理，且扩展性不佳。

我们的目标是将这种控制级别直接集成到 ClickStack 中。未来的更新将侧重于实现更细粒度的数据访问，并支持在角色级别定义过滤条件，以满足行级访问需求。这将使团队能够在单一平台管理应用程序和数据访问，从而避免依赖分散或手动的解决方案。

总结

RBAC 标志着 ClickStack 的一项重要进步，为平台内的资源和工作流带来了结构化、可扩展的访问控制。通过引入角色、细粒度权限以及与 ClickHouse Cloud 的无缝集成，团队现在能够实现更精确的访问管理，同时减少运营开销。

我们计划继续扩展这些功能，以支持更细粒度的数据访问。敬请关注后续更新。

Meetup 活动报名通知

好消息：ClickHouse Shanghai User Group第 3 届 Meetup 火热报名中，将于2026年5月16日在上海市浦东新区世纪大道1568号中建大厦33层 Optiver上海举行，扫码免费报名

/END/

试用阿里云 ClickHouse企业版

轻松节省30%云资源成本？阿里云数据库ClickHouse 云原生架构全新升级，首次购买ClickHouse企业版计算和存储资源组合，首月消费不超过99.58元（包含最大16CCU+450G OSS用量）了解详情：https://t.aliyun.com/Kz5Z0q9G