角色与权限策略
本文档将介绍 API7 企业版中的高级功能：角色和权限策略的概念。
概述
- 角色：定义具有特定访问级别的用户组。你可以创建自定义角色，对具有相似权限需求的用户进行分类。一个角色可以与多个权限策略相关联。
- 权限策略：它们充当蓝图，概述 API7 企业版中特定资源（例如，网关组、已发布的服务）的允许操作（权限）。单个权限策略可以共享并应用于多个角色，从而提高效率和一致性。
通过将权限策略与角色关联，你可以有效地为不同的用户组分配适当的访问级别。这简化了访问控制管理，并确保用户只有执行其任务所需的权限。
角色和权限策略如何工作
考虑这样一种场景：你创建了一个名为 Gateway Group Manager 的自定义角色，并将其关联到名为 Gateway Group Basics Actions 的权限策略。
此权限策略将 GetGatewayGroups 操作授予所有网关组资源（资源范围为 *），允许具有 Gateway Group Manager 角色的用户在仪表板上查看网关组列表，并直接使用 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 等开发环境中更宽松的设置相比，这允许你在生产等环境中实施更严格的访问限制。
- 定义精细权限策略
为每个网关组创建特定的权限策略，例如 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 测试和发布任务。
如何配置权限策略
API7 企业版目前将权限策略存储为 JSON 文档。
// PermissionPolicy demo
{
"statement": [
{
"resources": [
"arn:gatewaygroup:<[^:]*>"
],
"actions": [
"GatewayGroup:DeleteGatewayGroup"
],
"conditions": {
"gateway_group_label": {
"type": "MatchLabel",
"options": [
{
"key": "env",
"operator": "exact_match",
"value": "prod"
}
]
}
},
"effect": "allow"
}
]
}
- API7 企业版中的单个权限策略可以包含多个语句，这些语句在它们管理的资源或操作方面可能重叠。通常，策略中的语句以 OR 关系发挥作用。如果任何单个语句授予用户权限（使用“允许”），则他们被授权对指定资源执行操作。
- 一个语句定义允许的操作和资源，效果可以是允许或拒绝。API7 企业版对权限策略执行“拒绝覆盖允许”的原则。对某个具体用户来说，无论来自哪个角色和关联的权限策略，“拒绝”语句总是覆盖同一操作和资源的“允许”语句。
- 可选条件允许利用共享特定标签的灵活资源组，简化策略管理，提高可扩展性和可维护性。
示例
在此示例中，假设有三个网关组：
- 名称：测试网关组，带有标签
test、department A - 名称：蓝色网关组，带有标签
prod、department B - 名称：绿色网关组，带有标签
prod、department A
假设一个拥有上一个小节中示例权限策略的角色的用户。此用户可以通过控制台或 API7 工具删除 蓝色网关组 和 绿色网关组，但不能删除 测试网关组。
但是，如果 测试网关组 的标签更改为 prod，则由于匹配标签成功，用户可以将其删除。同样，新创建的带有 prod 标签的 黑色网关组 也将被此用户删除。
关于在权限策略条件中使用标签
在权限策略条件中使用标签而不是使用资源 ID 可以具有以下优点和缺点：
优点
- 动态访问控制：标签具有适应性，可以独立于资源 ID 进行更新。这允许在不影响资源标识的情况下修改访问控制策略。
- 可扩展性：单个标签可以应用于多个资源，从而简化了不断增长的资源的策略管理。使用标签可以避免以下情况：用户创建新资源（例如，网关组）但无法访问它，因为引用旧资源 ID 的权限策略不包含新资源 ID。
- 可维护性：引用标签的策略不太可能因资源 ID 的更改而中断。
缺点
- 清晰度降低：标签引入了一个抽象层，可能会使人更难一目了然地了解策略适用于哪些特定资源。
- 错误配置风险：不一致或不准确的标签可能会导致意外的访问授予或拒绝。
- 动态访问控制导致意外行为：虽然标签提供了灵活性，但它们可以引入动态访问控制。这意味着用户访问特定资源的能力可能会根据资源标签的更新而发生变化，与使用静态资源 ID 相比，这可能会导致访问行为更不可预测。
找到合适的平衡：
- 用于更广泛类别的标签：将标签用于更广泛的访问控制类别（例如，“生产”、“测试”）。
- 用于粒度控制的资源 ID：对需要细粒度控制的特定资源使用资源 ID（例如，关键 API 端点的唯一 ID）。
- 清晰的标签规划：确保在整个 API 环境中保持一致且定义明确的标签约定。
通过了解这些权衡并实施最佳实践，你可以有效地利用标签来增强 API7 企业版权限策略的安全性和可管理性。
使用技巧
授予最小权限
仅授予用户在 API 环境中执行指定任务所需的最小权限。为了实现这一点，首先要明确定义用户和角色的需求。然后，制定具有一组受限操作和资源的权限策略。最后，仅在绝对必要时添加更多权限，确保效率和强访问控制之间的平衡。
优点：
- 减少攻击：限制权限可最大限度地减少受感染帐户的潜在影响。
- 增强问责制：明确的用户访问限制可促进更好的所有权和责任感。
- 简化管理：维护最小权限简化了权限管理并降低了意外疏忽的风险。
配置角色和权限策略的权限
与 API7 企业版中的其他资源一样，角色和权限策略本身也需要明确定义的访问控制。以下是两种常用方法：
集中的角色和权限策略管理：指定专门的用户同时负责更新角色本身并修改其所有关联权限策略，以及将角色授权给其他用户。通过一起管理这两个方面来简化他们的工作流程。在这种情况下，用一对一的原则设计角色和权限策略有助于简化。
隔离管理角色和权限策略：指定专门的用户只负责更新角色及其关联权限策略，但不负责将角色授权给用户。这适合角色内容相对稳定，但用户频繁流动变化的情况。
最佳方法取决于你的具体需求。考虑以下因素：
- 角色成员变更的频率
- 维持稳定角色和策略内容的必要性