Zadig基于OPA方案的RBAC和ABAC权限管理技术方案详解。经过深入研究，我们最终决定采用OPA（OpenPolicyAgent）开源策略引擎。事实上，它已被Netflix、Pinterest和高盛等公司用于生产，并正在成为云原生策略管理的事实标准。但是OPA的编写有一定的复杂性，网上的教程和官方文档都只停留在Demo层面。经过Zadig从v1.9.0到v1.10.0的迭代，我们已经完全实现了RBAC和ABAC权限管理业务和技术方案的落地。在这里，我们将与您分享整个解决方案的技术细节。背景OPAOpenPolicyAgent（发音为“oh-pa”）是一个开源通用策略引擎，它统一了跨技术栈的策略执行。OPA提供了一种高级声明性语言rego，允许您将策略指定为代码和一个简单的API以在软件中加载策略决策。您可以使用OPA在微服务、Kubernetes、CI/CD管道、API网关等中执行策略定义角色并通过角色控制权限。目前，基于角色的访问控制模型被广泛应用，尤其是在2B方向的SAAS领域，其应用尤为普遍。如上图，一个用户有一个角色，可以有多个角色，每个角色对应不同的权限。这样做的好处是不需要为每个用户都配置权限，具有很大的灵活性和方便性。ABAC：基于属性的访问控制模型（ABAC：Attribute-BasedAccessControl），被一些人称为权限系统设计的未来，在某种程度上不同于常见的将用户与权限相关联的方式，ABAC是通过动态计算是否一个或一组属性满足一定条件进行授权判断（可以写简单的逻辑）。属性一般分为四类：用户属性（如用户年龄）、环境属性（如当前时间）、操作属性（如阅读）和对象属性（如文章，又称资源属性），所以理论上它可以实现非常灵活的权限控制，几乎可以满足所有类型的需求。Zadig目前主要通过标签模拟属性来实现细粒度的资源权限控制。图片来源：阿里云帮助文档Zadig权限场景系统级角色-解决全系统权限问题（RBAC）管理员：拥有全系统权限普通用户：拥有公共项目及其所有资源查看权限、测试管理和查看权限用于数据分析项目级角色——解决项目级权限问题（RBAC）项目下工作流和集成环境列表的权限（但资源会被精细化管理），以及服务、构建和测试资源的所有查看权限。自定义角色：自定义各个模块的权限能力。项目级资源精细化管理（ABAC）因此Zadig在OPA的基础上实现RBAC解决系统和项目的通用权限管理，实现ABAC解决项目级资源的精细化管理。ZadigAuthorityArchitectureDesignAuthorityDesignArchitectureDiagramGloo作为Zadig的门户，是Zadig所有交通的入口。集成OPA后，所有经过网关的流量都会统一经过OPA的鉴权认证，认证鉴权通过后才允许访问后端服务（aslan）。另外，OPA决策所依赖的数据会异步定时的去到权限管理服务（policy）和后端服务（aslan）去收集决策所需要的权限和资源数据，从而达到高性能决策。zadig权限数据库模型zadig-policy数据库中相关数据模型角色：用户角色定义表，用于定义某个项目下的角色。如下记录说明在“zadig”项目下有一个“dev”角色，具有查看Workflows的能力和执行工作流的权限。rolebinding：用户角色绑定表，用于将角色绑定到用户。如下记录表示“zadig”项目下的“dev”角色绑定uid为“71b8aa87-a10b-11ec-af4e-fa012450189e”用户policy_meta：权限元信息表，用于将业务语义权限转化为对应的[端点+动作]。提供给opa的bundle数据中role下的权限会转换成一组url。转换后，具体内容可以在决策数据中的rolespolicy中看到：用户策略定义表，用于定义某个项目下的策略。如下记录表明在“zadig”项目下有一个“zadig-dev-system-zhangsan”策略和角色表。相同，主要区别在于policy表中多了一个match_attributes字段，表示有权限查看工作流和执行工作流policybinding：userpolicybinding表，用于给用户绑定策略，如下记录表示将“zadig”项目下的“zadig-dev-system-zhangsan”策略绑定到uid为“4fd92962-a4f6-11ec-af4e-fa012450189e”用户的Zadig数据库中的相关数据模型标签：标签表，该标签会同时标注在权限规则和资源上，表示带有该标签的资源具有权限具有相关权限labelbinding：标签资源关联表，记录了标签与资源的绑定关系。RBAC实施决策数据。决策数据是指提供给OPA用于决策的元数据集。包括权限数据和资源数据，主要来自于OPA术语，称为bundleforrightsmanagementservice(policy)andbackendservice(aslan)。OPA会缓存bundle以提高决策效率。以下是决策数据的目录结构。roles：角色数据，数据来自上面的role和policy_meta表，收集的时候会进行组装，所以这里的规则就是最终的组装结果bindings：role_bindings：角色绑定数据，数据主要来自上面的rolebinding表资源:资源数据，zadig目前提供了项目下细粒度资源的权限控制，所以需要收集工作流和环境相关的资源工作流：工作流收集数据，原始数据存放在后端服务（aslan）环境:收集数据，原始数据存储在后端服务(aslan)examples:specialurlcollectionpublic:zadigpublicurls,allusers(includingnon-logged-inuserscanaccess)Privileged:zaidgprivilegedurls,只有系统管理员用户canaccessRegistered:zadigallregisteredurls,unregisteredurls默认登录用户可以访问OPA，实现认证过程：检查url是否未注册，如果未注册，则返回传递的用户是否为admin，如果是，则返回传递的请求是否满足，url不是特权url，用户为项目的项目管理员，如果是，则返回是否满足pass请求满足，url不是特权url，且请求匹配用户绑定的角色，如果是，则返回pass（权限没有标签，即rule中没有rule有matchAttributes关键代码(rego)：ABAC实现决策数据决策数据解释同RBAC决策数据。bindings:policy_bindings：策略绑定数据，数据来自上面的策略绑定表。policies：策略数据，数据来自上面的策略表，相对于roles，它的rule的matchAttributes会有一个label，用来过滤匹配的资源。resources：相对于rbac的资源集合，这里的resourcespec会有一个标签，用于细粒度的资源匹配。OPA实现鉴权流程：单个资源请求匹配，请求是否满足url不是特权url，用户绑定的策略权限规则匹配请求，权限的标签匹配请求的资源标签用户，如果是，则返回pass(permissionLabeled，即规则中的matchAttributes)如果以上都不满足，则进行多资源请求匹配，用户绑定的policy权限规则匹配该请求.如果满足，则过滤匹配到的资源（带标签的权限，即带matchAttributes的规则）如果都不满足，则返回鉴权失败的关键码（rego）：以上实现可参考Zadig源码位置:pkg/microservice/policy/core/service/bundle/rego/authz.rego期待以上我们对Zadig基于OPA的权限架构设计、数据库模型实现以及RBAC和ABAC实现的详细讲解，希望能给大家带来思考和帮助。通过这样的权限管理方案，可以实现更多实用的功能。例如，在下个版本中，将提供按项目细粒度的权限控制隐藏和关闭前端按钮、系统角色权限管理和群组管理能力以及服务粒度权限控制等。官网：https://koderover.com/github：https://github.com/koderover/zadig
