角色与权限策略
在本文档中，你将了解角色（Roles）和权限策略（Permission Policies）的概念，这是 API7 企业版中一项高级且独有的功能。
概览
角色（Roles）：定义具有特定访问级别的用户组。你可以创建自定义角色，对具有相似权限需求的用户进行分类。一个角色可以关联多个权限策略。
权限策略（Permission Policies）：它们充当蓝图，概述了对 API7 企业版中特定资源（如网关组、已发布的服务）允许执行的操作（权限）。单个权限策略可以共享并应用于多个角色，或直接作为权限边界（permission boundary）应用于用户。
使用权限策略有两种方法：
- 通过将权限策略与角色相关联，你可以有效地将适当的访问级别分配给不同的用户组。这简化了访问控制管理，并确保用户仅具有执行其任务所需的权限。
- 将权限策略作为边界应用于特定用户，将定义该用户允许的最大权限，作为防止过度权限提升的保护措施。
通常，用户的有效权限是由分配的角色和权限边界的交集决定的。
角色和权限策略的工作原理
仅当满足以下条件时，用户的操作才被允许：
- 被至少一个分配的角色允许。
- 被至少一个权限边界允许（如果存在）。
- 未被任何分配的角色或权限边界拒绝。
设想这样一种情况：你创建了一个名为 网关组管理员 的自定义角色，并将其附加到一个名为 网关组基础操作 的权限策略。
该权限策略将 GetGatewayGroups 操作授予所有网关组资源（资源范围为 *），允许具有 网关组管理员 角色的用户在控制台上查看网关组列表，并使用“获取所有网关组” API 直接检索网关组列表，或利用 ADC 和 API7 Ingress Controller 等 API7 工具。
还要创建一个名为 禁止许可证操作 的权限策略，该策略将拒绝所有与许可证相关的操作。将此权限策略应用为用户的权限边界，然后它将对许可证强制执行严格的访问限制，防止用户超越预定义的权限，无论分配了什么角色。
要点：
- 角色用于根据共享的权限要求对用户进行分类。对附加到角色的权限策略的更改将传播到该角色中的所有用户。
- 权限策略指定对 API7 企业版（包括 API7 网关和 API7 门户）内指定资源的授权或禁止操作。
- 将权限策略附加到多个角色，可将相关的权限授予这些角色内的所有用户。
- 权限策略可以根据需要进行详细或广泛的设置。从一组基本策略开始，并随着你的访问控制需求的发展进行完善。
- 权限边界限制了允许用户使用的最大权限，无论分配给他们的是什么角色。用作用户权限边界的权限策略通常包含一组 拒绝（deny）语句。
用例
内置的超级管理员角色（Super Admin）
API7 企业版从一个预定义、名为 Super Admin 的角色开始进行初始系统设置。此角色与内置的 super-admin-permission-policy 相关联，授予对 API7 企业版内所有操作和资源的完全访问权限。预定义的角色和策略都是不可编辑的，以确保核心系统的安全。
初始 admin 账户永久绑定到 Super Admin 角色，并且无法更改其角色。
使用自定义角色扩展访问控制
虽然内置角色和策略提供完全访问权限，但 API7 企业版使你能够创建具有细粒度权限的自定义角色。对于需要广泛访问的场景，你甚至可以将 super-admin-permission-policy 附加到你的自定义角色中。
这是一个示例场景：隔离环境并定制安全性
通过将权限策略与特定的网关组关联，你可以为每个环境定义细粒度的安全控制。这使你能够在生产环境（Production）等环境中实施更严格的访问限制，而在测试（Test）或 UAT 等开发环境中的设置相对宽松。
- 定义细粒度权 限策略
为每个网关组创建特定的权限策略，例如 test-gateway-group-full-access、uat-gateway-group-full-access 和 production-gateway-group-full-access。这些策略将定义每个环境允许的操作和资源。
- 分配具有受控访问权限的角色
创建自定义角色，对具有相似访问需求的用户进行分类。 将适当的权限策略附加到每个角色：
- 开发团队成员：授予对
test-gateway-group-full-access策略的访问权限，允许他们仅在测试环境中进行更改。 - 开发团队负责人：分配对
test-gateway-group-full-access和uat-gateway-group-full-access策略的访问权限。这使他们能够在测试和 UAT 环境中工作，可能还包括将稳定配置从测试环境同步到 UAT 的能力。 - 测试工程师：附加
uat-gateway-group-full-access和production-gateway-group-full-access策略。这将限制其访问 UAT 和生产环境，重点关注新 API 测试和发布任务。
防止用户超越预定义权限
用户的角色可能会经常更改，你可能需要一种保障措施来确保限制生效。例如，权限边界可用于防止部门 A 的用户访问部门 B 拥有的资源。 权限边界还可以用于防止意外访问诸如许可证或组织设置等关键系统组件。通过明确拒绝访问这些区域，你可以创建强大的安全层来保护敏感配置免受未经授权的修改。
如何配置权限策略
API7 企业版目前将权限策略存储为 JSON 文档。创建和编辑这些策略需要使用 JSON 编辑器定义细节，然后手动将编辑好的 JSON 代码复制回 API7 企业版进行配置。
API7 企业版的未来版本计划包含权限策略的可视化编辑器。请持续关注更新。
JSON 策略文档结构
如下例所示，JSON 策略文档包含以下元素：
// PermissionPolicy demo
{
"statement": [
{
"resources": [
"arn:gatewaygroup:<[^:]*>" // 必填字段，可操作资源的范围，由资源 ID 指定，可以使用通配符。在此示例中，它指的是所有网关组资源。
],
"actions": [
"GatewayGroup:DeleteGatewayGroup" // 必填字段，允许的操作，从预定义的操作集中选择。请注意，操作应与资源类型兼容。在此示例中，它指的是删除网关组的操作。
],
"conditions": { // 可选字段，通过标签（label）过滤可操作资源。在此示例中，它指的是带有“Environment Type: Production”标签的所有网关组。
"gateway_group_label": {
"type": "MatchLabel",
"options": [
{
"key": "EnvType",
"operator": "exact_match",
"value": "Production"
}
]
}
},
"effect": "allow"
}
]
}
- API7 企业版中的单个权限策略可以包含多条语句（statement），这些语句在管理的资源或操作方面可能会重叠。通常，策略内的语句以“或（OR）”的关系起作用。如果任何一条单独的语句向用户授予了权限（使用 "allow"），则授权他们在指定的资源上执行该操作。
- API7 企业版对权限策略强制执行“拒绝优先于允许（deny overrides allow）”的原则。
- 对于特定角色，如果关联了多个权限策略，只要其中一个策略中有任何定义为“deny”的 语句，那么所有其他关联的权限策略中对于相同资源和操作的所有“allow”语句将失效。
- 对于特定用户，如果任何角色或用户的权限边界策略最终对特定资源和操作得出“deny”，那么即使用户的其他角色允许了，该用户也无法对此资源执行指定的操作。
示例
在此示例中，假设有三个网关组：
- 名称：Test gateway group，带有标签
EnvType:Test,Department:A - 名称：Blue gateway group，带有标签
EnvType:Production,Department:B - 名称：Green gateway group，带有标签
EnvType:Production,Department:A
假设为用户分配了一个带有上述示例权限策略的角色。此用户可以通过控制台或 API7 工具删除 Blue gateway group 和 Green gateway group，但不能删除 Test gateway group。
但是，如果 Test gateway group 的标签更改为 EnvType:Production，则该用户因为标签匹配就可以删除它了。同样，由该用户创建带有 EnvType:Production 标签的新 Black gateway group，也是可以被此用户删除的。
关于在权限策略条件中使用标签
在权限策略条件中使用标签而不是使用资源 ID 可能具有以下优缺点：
优点
- 动态访问控制：标签具有适应性，可以随时更新。而资源 ID 不能编辑。
- 可扩展性：可以将单个标签应用于多个资源，简化对不断增长资源的策略管理。使用标签可避免出现以下情况：用户创建新资源（例如网关组），但因为引用旧资源 ID 的权限策略中不包含新资源 ID，导致无法访问它。
缺点
- 清晰度降低：标签引入了抽象层，可能导致更难以一眼就明白策略适用于哪些特定资源。
- 配置错误风险：不一致或不准确的标签可能会导致意外的访问授权或拒绝。
- 动态访问控制导致意外行为：尽管标签提供了灵活性，但它们可以引入动态访问控制。这意味着用户访问特定资源的能力可能会根据资源标签的更新而改变，相较于使用静态的资源 ID 来说，访问行为的可预测性较差。
找到合适的平衡：
- 用于更广泛类别的标签：对更广泛的访问控制类别（例如“生产”、“测试”）使用标签。
- 用于细粒度控制的资源 ID：将资源 ID 用于需要细粒度控制的特定资源（例如，对关键 API 端点使用唯一的 ID）。
- 清晰的标签实践：确保在你的 API 环境中实施一致且良好定义的标签规范。
通过了解这些优缺点并实施最佳实践，你可以有效地利用标签来增强 API7 企业版权限策略的安全性和可管理性。
实用提示
授予最小权限
只向用户授予其在 API 环境中执行指定任务所需的最少权限。为此，首先明确定义用户和角色的需求；然后，用一组受限的操作和资源制定权限策略；最后，仅在绝对必要时添加更多权限，确保效率和强访问控制之间的平衡。
好处：
- 减少攻击面：限制权限可最大程度地减少泄露帐户带来的潜在影响。
- 增强问责制：明确的用户访问限制能提升所有权及责任感。
- 简化管理：维护最小权限能简化权限管理并降低意外疏忽的风险。
配置角色和权限策略的权限
与 API7 企业版中的其他资源一样，角色和权限策略本身也需要明确定义的访问控制。以下是两种常见的方法：
-
合并权限：指定的用户可以更新角色本身并修改所有附加的权限策略。这通过同时管理这两个方面简化了他们的工作流程。在此场景下，只将所有的权限策略附加到单个角色中，可以帮助简化设计。
-
独立访问控制：分别管理角色和权限策略的访问控制。这允许角色内用户的频繁变更，同时保持策略内容的稳定。
最佳方法取决于你的具体需求。请考虑以下因素：
- 角色成员变动的频率
- 维持策略内容稳定性的重要性