设计自定义角色体系

随着组织规模扩大，访问控制会变得更加复杂，无法再简单地为所有人授予宽泛的管理员权限。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 用户测试重大策略变更。
• 记录每个共享角色和权限策略的负责人。

何时创建新角色

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

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

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

后续步骤

• 创建自定义角色——通过组合权限策略构建具体角色。
• 基于角色的访问控制（RBAC）——了解访问权限的评估方式。
• 权限策略和权限边界——编写策略 JSON 和权限边界。
• 权限策略示例——选用适合组织的现成示例。