角色与权限策略
本文档将介绍 API7 企业版中的高级功能：角色和权限策略的概念。
概述
- 角色：定义具有特定访问级别的用户组。你可以创建自定义角色，对具有相似权限需求的用户进行分类。一个角色可以与多个权限策略相关联。
- 权限策略：它们可以被视为一种蓝图，用来概括 API7 企业版中特定资源（例如，网关组、已发布的服务）的允许操作（权限）。单个权限策略可以被多个角色同时关联，也可以被直接用作某些用户的权限边界，从而防止用户越权。
角色和权限策略工作原理
考虑这样一种场景：你创建了一个名为 网关组管理员 的自定义角色，并为其关联名为 网关组基本操作 的权限策略。
此权限策略将 GetGatewayGroups 操作授予所有网关组资源（资源范围为 *），允许用户在控制台上查看网关组列表，并直接使用 Get all gateway groups API 或利用 API7 工具（如 ADC 和 API7 Ingress Controller）检索网关组列表。
关键点：
- 角色用于根据用户的共享权限要求对用户进行分类。对角色的关联权限策略的更改将影响该角色关联的所有用户。
- 权限策略指定了 API7 企业版（包括 API7 网关 和 API7 门户）内指定资源的授权操作。
- 将权限策略关联到多个角色会将关联的权限授予这些角色中的所有用户。
- 权限策略可以根据需要进行详细或广泛的定义。建议从基本设置开始，然后随着访问控制要求的发展对其进行细化。
使用案例
内置超级管理员角色
API7 企业版在初始系统设置时提供了一个预定义的角色，名为 超级管理员。此角色与内置的 super-admin-permission-policy 相关联，该策略授予对 API7 企业版内所有操作和资源的完全访问权限。内置的角色和策略都是不可编辑的，以确保核心系统安全。
初始 admin 帐户永久绑定到 超级管理员 角色，并且其角色无法更改。
使用自定义角色扩展访问控制
API7 企业版中还能够创建具有精细权限的自定义角色。对于需要完全访问的场景，你也可以直接将 super-admin-permission-policy 关联到你的自定义角色。
示例场景：隔离环境和定制安全性
通过将权限策略限定在特定网关组的资源范围内，你可以为每个环境定义精细的安全控制。与测试或 UAT 等开发环境中更宽松的权限设置相比，你可以在生产等环境中实施更严格的访问限制。
- 定义权限策略
为每个网关组创建特定的权限策略，例如 测试网关组完全操作、UAT网关组完全操作 和 生产网关组网完全操作。这些策略分别定义了每个网关组（对应不同环境）中允许的操作和资源。
- 分配角色
创建自定义角色以对具有相似访问需求的用户进行分类，然后将适当的权限策略关联到每个角色：
- 开发团队成员：关联
测试网关组完全操作策略，允许他们仅在测试环境中进行更改。 - 开发团队领导：关联
测试网关组完全操作和UAT网关组完全操作策略。这使他们能够在测试和 UAT 环境中工作，还包括将服务版本从测试同步到 UAT 的能力。 - 测试工程师：关联
UAT网关组完全操作和生产网关组完全操作策略。这将他们的访问权限限制在 UAT 和生产环境，专注于新的 API 测试和发布任务。
防止用户越权
用户的角色可能经常发生变化，因此你可能需要一种保障措施来确保边界限制。 例如，权限边界可用于防止 A 部门用户访问 B 部门拥有的资源。权限边界还可用于防止意外访问关键系统组件，例如许可证或组织设置。通过明确拒绝访问这些区域，你可以维持一个强大的安全层，保护敏感配置免遭未经授权的修改。
如何配置权限策略
API7 企业版目前将权限策略存储为 JSON 文件。
// PermissionPolicy 示例
{
"statement": [
{
"resources": [
"arn:gatewaygroup:<[^:]*>" // 必填字段，可操作的资源范围，通过资源 ID 指定，可使用通配符。此示例中指所有网关组资源。
],
"actions": [
"GatewayGroup:DeleteGatewayGroup" // 必填字段，允许的操作，从预定义好的操作集合中选择，注意和资源类型要配套。此示例中指删除网关组的操作。
],
"conditions": { // 可选字段，用标签筛选可操作的资源范围。此示例中指所有带“环境类型：生产”标签的网关组。
"gateway_group_label": {
"type": "MatchLabel",
"options": [
{
"key": "环境类型",
"operator": "exact_match",
"value": "生产"
}
]
}
},
"effect": "allow" // 必填字段，指定 actions 的效果，只能是 allow 或者 deny。
}
]
}
- API7 企业版中的单个权限策略可以包含多个语句（Statement），这些语句定义的资源和操作可以重叠， 它们之间是 OR 的关系。
- API7 企业版对权限策略执行“拒绝覆盖允许”的原则。
- 对某个具体角色来说，如果关联了多个权限策略，只要有任意一个策略中有任意一个语句（Statement）定义为“拒绝”（deny），则其他关联的权限策略中所有语句中对同一个资源及操作的“允许”（allow）都将无效。
- 对某个用户来说，如果被授权了多个角色，只要有任意一个角色或该用户的权限边界策略最终拒绝了对某一个资源及操作的“拒绝”（deny），则无论其他角色是否允许，该用户都无法对这个资源进行指定的操作。
示例
假设有三个网关组：
- 名称：测试网关组，带有标签
环境类型：测试、部门： A - 名称：蓝色网关组，带有标签
环境类型：生产、部门： B - 名称：绿色网关组，带有标签
环境类型：生产、部门： A
假设一个自定义角色，关联了上一个小节中示例权限策略，有一个用户被授予了这个角色。此用户可以通过控制台或 API7 工具删除 蓝色网关组 和 绿色网关组，但不能删除 测试网关组。
但是，如果 测试网关组 的标签更改为 生产，则由于匹配标签成功，用户可以将其删除。同样，新创建的带有 环境类型：生产 标签的 黑色网关组 也将能够被此用户删除。
在权限策略条件中使用标签
在权限策略条件中使用标签具有以下优点和缺点：
优点
- 动态访问控制：标签可以随时改变，但资源 ID 不可变更。使用标签可以在不改变权限策略本身的情况下变更对资源的访问控制。
- 可扩展性：单个标签可以应用于多个资源，方便批量授权管理。使用标签可以避免以下情况：用户创建新资源（例如，网关组）但无法访问它，因为权限策略中只会引用其他存量资源 ID，无法包括还没创建出来的新资源 ID。
缺点
- 清晰度降低：标签引入了一个抽象层，可能会使人更难一目了然地了解策略适用于哪些特定资源。
- 错误配置风险：不一致或不准确的标签可能会导致意外的访问授予或拒绝。
- 动态访问控制导致意外行为：虽然标签提供了灵活性，但它们可以引入动态访问控制。这意味着用户访问特定资源的能力可能会根据资源标签的更新而发生变化，与使用静态资源 ID 相比，这可能会导致访问行为更不可预测。
找到合适的平衡：
- 标签适用较宽泛的分类：将标签用于更宽泛的访问控制类别（例如，“生产”、“测试”）。
- 细粒度控制使用资源 ID：对需要细粒度控制的特定资源使用资源 ID。
- 清晰的标签规划：确保在整个 API 环境中保持一致且定义明确的标签定义。
通过了解这些利弊并实施最佳实践，你可以有效地利用标签来增强 API7 企业版权限策略的安全性和可管理性。
使用技巧
授予最小权限
仅授予用户在 API 环境中执行指定任务所需的最小权限。为了实现这一点，首先要明确定义用户和角色的需求。然后，制定具有一组受限操作和资源的权限策略。最后，仅在绝对必要时添加更多权限，确保管理效率和强访问控制之间的平衡。
优点：
- 减少攻击：限制权限可最大限度地减少风险帐户的潜在影响。
- 增强问责制：明确的用户访问限制可促进更好的所有权和责任感。
- 简化管理：维护最小权限简化了权限管理并降低了意外疏忽的风险。
配置角色和权限策略的权限
与 API7 企业版中的其他资源一样，角色和权限策略本身也需要明确定义的访问控制。以下是两种常用方法：
集中的角色和权限策略管理：指定专门的用户同时负责更新角色本身并修改其所有关联权限策略，以及将角色授权给其他用户。通过一起管理这两个方面来简化他们的工作流程。在这种情况下，用角色和权限策略一对一的原则来设计有助于简化。
隔离管理角色和权限策略：指定专门的用户只负责更新角色及其关联权限策略，但不负责将角色授权给用户。这适合角色内容相对稳定，但被授予的用户频繁流动变化的情况。
最佳方法取决于你的具体需求。考虑以下因素来进行抉择：
- 角色成员变更的频率
- 维持稳定角色和策略内容的必要性