3. 跨团队协作中的数据角色与权限模型

在 Elastic 的跨团队数据共享场景中，最容易出问题的往往不是技术连通性，而是“谁能看到什么、能改什么、能删什么”。Elasticsearch 的权限体系围绕四个核心概念展开：用户（User）、角色（Role）、权限（Privilege）和空间（Space）。理解它们之间的映射关系，是把最小权限原则真正落地的第一步。

用户是身份主体，可以是内置用户、通过 LDAP/SAML/OIDC 接入的外部用户，也可以是 API Key 或 Service Token 这类程序化身份。角色是权限的集合，本身不绑定具体人，而是通过“角色映射”分配给用户或用户组。权限则是最细粒度的操作许可，分为集群级（cluster privileges）、索引级（index privileges）和空间级（Kibana privileges）三类。空间是 Kibana 中的逻辑隔离单元，用于把仪表板、可视化、保存对象按团队或业务域分开，同时决定哪些角色能在该空间内做什么。

下面这张图展示了四个概念之间的结构关系，以及权限从定义到生效的传递路径。它可以帮助你在设计权限模型时，快速定位“应该在哪一层做限制”。

理解了结构之后，落地时最常被问到的问题是：“我应该建几个角色？怎么划分才合理？”一个实用的做法是按“职责”而不是按“人”来建角色。例如，在一个日志分析平台中，可以设计三类基础角色：

• 数据只读角色（log_viewer）：对 logs-* 索引拥有 read 和 view_index_metadata 权限，在指定空间内可查看仪表板，但不能修改任何保存对象。
• 数据写入角色（log_writer）：对 logs-* 拥有 create_doc、index 权限，但不能删除索引，也不能读取其他团队的数据。
• 数据管理角色（log_admin）：拥有 manage、delete 等索引级权限，同时具备空间内仪表板的编辑权限，用于负责该业务域的运维人员。

角色建好后，通过角色映射把用户或用户组挂上去。例如，把 LDAP 中 cn=log-readers,ou=groups,dc=example,dc=com 映射到 log_viewer 角色，这样人员变动时只需调整目录服务中的组成员，Elastic 侧无需逐个改用户。对于程序化访问，建议为每个应用创建独立的 API Key，并在创建时限定其角色和有效期，而不是复用某个人的账号。

空间（Space）的使用也有讲究。空间不是越多越好，而是应该与团队边界或业务域边界对齐。例如，可以按“支付业务”“风控业务”“基础设施”划分三个空间，每个空间内放置该团队自己的仪表板、可视化和保存的搜索。角色在空间中的权限通过 kibana privileges 配置，可以精确到“能否创建可视化”“能否导出 CSV”“能否管理空间内的对象”等粒度。

下面给出一个可直接参考的角色定义示例，展示如何用 Elasticsearch 的 Role API 创建一个“只读 + 限定索引 + 限定空间”的角色。示例中的索引名、空间 ID 和权限项均为教学假设，实际使用时请替换为你的真实环境参数。

PUT _security/role/payment_log_viewer
{
  "cluster": ["monitor"],
  "indices": [
    {
      "names": ["payment-logs-*"],
      "privileges": ["read", "view_index_metadata"],
      "allow_restricted_indices": false
    }
  ],
  "applications": [
    {
      "application": "kibana-.kibana",
      "privileges": ["feature_dashboard.read", "feature_discover.read"],
      "resources": ["space:payment"]
    }
  ]
}

这段配置的含义是：该角色只能查看 payment-logs-* 索引，不能写入或删除；在 Kibana 中只能在 payment 空间内使用仪表板和 Discover 功能，不能编辑或创建保存对象。创建完成后，再通过角色映射把对应的用户组绑定到这个角色上：

PUT _security/role_mapping/payment_viewer_mapping
{
  "roles": ["payment_log_viewer"],
  "enabled": true,
  "rules": {
    "field": { "groups": "cn=payment-analysts,ou=groups,dc=example,dc=com" }
  }
}

验证权限是否按预期生效，最直接的方式是用目标用户登录 Kibana，检查三件事：第一，在 Discover 中能否看到 payment-logs-* 的数据，同时确认看不到其他索引；第二，尝试编辑一个仪表板，应该被拒绝；第三，切换到其他空间，应该无法访问或看不到任何对象。如果这三项都符合预期，说明最小权限模型基本落地成功。

最后需要强调的是，权限模型不是一次性的配置，而是需要持续维护的资产。建议定期做三件事：审查角色列表，删除不再使用的角色；检查 API Key 的有效期和权限范围，及时轮换或回收；核对角色映射规则，确保离职或转岗人员不再持有不必要的访问权限。把这些检查纳入日常运维流程，跨团队协作才能在安全与效率之间保持平衡。