跳到主要内容
版本：3.10.x

设计自定义角色体系

随着组织规模扩大，访问控制会变得更加复杂，无法再简单地为所有人授予宽泛的管理员权限。API7 网关支持组合用户、角色、权限策略和权限边界来设计自定义角色体系。

本指南介绍如何设计一套随着团队和环境增长仍然易于理解、安全且可维护的角色体系。

从访问模型开始​

创建角色前，请先定义希望权限策略支持的运作模型：

  • 哪些团队需要访问 API7 网关。
  • 团队应管理哪些环境，如 dev、test、staging 和 production。
  • 允许执行哪些操作，如只读查看、部署、运维或管理用户。
  • 哪些资源必须严格控制，如许可证、组织设置、凭据和生产网关组。

这样可以让角色体系与实际职责保持一致，而不是机械照搬组织架构。

核心设计原则​

优先授予最小权限​

从能让团队完成工作的最小权限集开始。只有在明确存在运维需求时才逐步扩大权限。

良好的起始模式包括：

  • 为审计、支持和合规工作流设置只读角色。
  • 为非生产和生产运维设置不同角色。
  • 将 IAM 管理与网关流量管理分离。

优先使用可复用权限策略​

设计小型、可复用的权限策略，并根据需要将其挂载到多个角色，使访问模型更易审查和更新。

例如，可以分别创建以下策略：

  • 只读访问生产网关组。
  • 完全访问测试网关组。
  • 管理用户和角色。
  • 查看审计日志。

然后将这些策略组合到符合实际职责的角色中。

使用标签实现规模化管理​

管理大量网关组、服务或团队时，应避免在每项策略中硬编码所有资源 ID。使用标签和基于标签的条件，可降低策略扩展时的维护成本。

例如：

  • env=production
  • team=payments
  • region=eu

这样从少量环境扩展到数十个环境时，无需重写每个角色。

分离角色设计与角色分配​

能够分配角色的人员不一定也应能够设计或编辑角色。许多组织只允许少数可信管理员定义策略和角色，而团队负责人或委派管理员只能向用户分配已批准的角色。

这种职责分离可以降低意外提权风险。

使用权限边界实现安全委派​

即使以后挂载了更宽泛的角色，权限边界也会限制用户能够拥有的最高权限。需要委派部分管理工作但又不允许权限无限扩大时，这一机制非常有用。

常见示例包括：

  • 永远不应访问生产环境的承包商。
  • 只能在有限范围内管理用户的团队负责人。
  • 为迁移或事件响应临时设置的管理员。

推荐的角色分层​

对许多团队来说，按层次思考比为每个人创建一个角色更有效。

平台管理员​

这些用户管理整个平台和组织级设置。

典型能力：

  • 管理用户、角色、权限策略和组织设置。
  • 管理所有网关组。
  • 查看审计日志和关键平台状态。

此类用户应保持少量。

环境运维人员​

这些用户管理特定环境中的流量资源。

典型模式：

  • 开发人员：完全访问 dev 和 test，不能写入生产环境。
  • 发布工程师：可以写入 staging，并受控访问 production。
  • SRE：具有跨环境的运维权限，但对 IAM 资源限制更严格。

只读用户​

这些用户需要查看资源，但不能更改。

常见示例：

  • 审计人员
  • 支持工程师
  • 安全审查人员

委派管理员​

这些用户管理范围受限的一部分 IAM 或网关资源。

常见示例：

  • 为团队成员分配预先批准角色的团队负责人。
  • 可以维护用户和角色但不能修改流量配置的角色管理员。

设计模式示例​

环境隔离​

为每个环境创建独立权限策略，然后组合成角色。

例如：

  • production-readonly
  • test-full-access
  • staging-full-access

开发人员角色可组合 test-full-access 和 staging-full-access；审批人员角色可组合 production-readonly 和 staging-full-access。

按团队管理​

多个团队共享同一 API7 网关部署时，请使用标签隔离所有权。

例如：

-网关组或服务带有 team=payments 标签。

  • 策略仅在该标签匹配时允许访问。

即使共享同一平台，各团队也可以在自己的边界内运作。

集中管理角色并在本地委派​

由少数中央管理员定义策略和角色，再允许团队负责人向本团队用户分配已批准角色；最好同时使用权限边界防止越权。

相比允许每个团队从头设计访问模型，这种方式通常更容易治理。

审查清单​

采用角色设计前，请检查以下问题：

  • 每个角色是否对应实际运维职责？
  • 只需读取权限的角色是否能够修改生产环境？
  • 不应管理网关流量的 IAM 管理员是否也能更改流量配置？
  • 资源范围是否足够窄，还是使用了不必要的通配符？
  • 标签能否减少策略重复？
  • 是否应为某些用户应用权限边界？
  • 是否定义了定期审查角色和策略分配的机制？

运维实践​

长期保持角色体系健康：

  • 定期审查角色分配并移除不再使用的权限。
  • 优先更改策略挂载关系，避免创建大量近似角色。
  • 审计宽泛的通配符权限，并明确记录其理由。
  • 广泛上线前，使用非 root 用户测试重大策略变更。
  • 记录每个共享角色和权限策略的负责人。

何时创建新角色​

仅在至少满足以下一个条件时创建新角色：

  • 团队拥有现有角色无法匹配的长期职责。
  • 需要不同的环境范围。
  • 合规或风险降低要求职责分离。
  • 某个可复用的策略组合将分配给多个用户。

如果需求是临时或特定于单个用户，使用权限边界或直接调整分配关系，可能比创建另一个长期角色更合适。

后续步骤​