3、权限模型基础：RBAC模型介绍、ABAC模型介绍、ReBAC模型介绍、权限模型选型原则

在构建平台工程的 CI/CD 服务目录时，权限模型是决定安全性与可维护性的核心架构决策。不同的权限模型在表达能力、管理成本和运行时性能上存在显著差异。本章将系统介绍三种主流权限模型——RBAC、ABAC 和 ReBAC，并给出在服务目录场景下的选型原则。

3.1 RBAC 模型（基于角色的访问控制）

RBAC（Role-Based Access Control）是当前企业级应用中最广泛使用的权限模型。其核心思想是将权限授予“角色”，再将角色授予“用户”，从而解耦用户与权限的直接绑定关系。

RBAC 的权限判定逻辑可以形式化表示为：

# RBAC 判定伪代码
def has_permission(user, action, resource):
    user_roles = get_user_roles(user)          # 获取用户的所有角色
    for role in user_roles:
        role_permissions = get_role_permissions(role)  # 获取角色的权限集
        if (action, resource) in role_permissions:
            return True
    return False

RBAC 的优缺点对比：

3.2 ABAC 模型（基于属性的访问控制）

ABAC（Attribute-Based Access Control）通过评估用户、资源、环境和操作的多维属性组合来做出权限决策。相比 RBAC 的“角色”单一维度，ABAC 提供了更细粒度和动态的权限控制能力。

ABAC 的典型策略表达式：

# ABAC 策略示例（使用 Rego 语言风格）
allow {
    input.user.role == "developer"
    input.resource.environment == "staging"
    input.action == "deploy"
    time.now_hour >= 9
    time.now_hour <= 18
    input.user.ip in ["10.0.0.0/8", "172.16.0.0/12"]
}

ABAC 与 RBAC 的核心差异：

3.3 ReBAC 模型（基于关系的访问控制）

ReBAC（Relationship-Based Access Control）以资源之间的“关系图”作为权限判定的核心依据。Google Zanzibar （2019）将其推广至生产级规模，现已被 Auth0、Keto、SpiceDB 等项目广泛采用。

ReBAC 的典型数据模型（以 SpiceDB Schema 为例）：

// ReBAC Schema 示例：CI/CD 服务目录权限
definition user {}

definition team {
    relation member: user
    relation owner: user
}

definition project {
    relation team: team
    permission view = team->member
    permission deploy = team->owner
}

definition pipeline {
    relation project: project
    permission trigger = project->deploy
    permission view_log = project->view
}

三种模型的对比总结：

3.4 权限模型选型原则

在平台工程的 CI/CD 服务目录场景下，选型不应追求“最先进”，而应追求“最匹配”。以下是基于实际工程经验的选型决策树：

1. 先评估组织规模与角色数量：如果角色数量 < 20 且权限粒度要求为“角色级”，优先选择 RBAC。
2. 再评估条件约束复杂度：如果存在“仅允许特定时间/IP/环境”等条件约束，必须引入 ABAC 或 RBAC+ABAC 混合模型。
3. 再评估资源层级深度：如果资源存在多层嵌套关系（如 组织→项目→流水线→部署环境），且权限需要沿层级传播，优先选择 ReBAC。
4. 最后评估团队运维能力：ABAC 和 ReBAC 需要策略引擎或图数据库的运维经验，如果团队缺乏相关能力，建议从 RBAC 起步，逐步演进。

选型决策矩阵：