你既然认准一条道路,何必去打听要走多久。
众所周知,OpenStack使用基于角色的权限访问控制(RBAC),在RBAC中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。角色可依新的需求和系统的合并而赋予新的权限,而权限也可根据需要而从某角色中回收。角色与角色的关系可以建立起来以囊括更广泛的客观情况。为了更好的适应OpenStack的角色权限管理,oslo项目创建了oslo.policy子项目为所有OpenStack服务提供RBAC策略实施支持。本文将详细介绍oslo.policy的实现与使用。
策略规则表达式
在通用的策略引擎实现中,策略规则表达式一般包含一个目标和一个相关联的规则。具体示例如下:
1 | "<target>": <rule> |
其中,target指定了正在执行策略的服务;通常,一个target指的是一个API调用。rule代表了具体的策略规则,一般可以用以下两种形式表示:一个使用新策略语法写成的字符串或者一个策略规则的列表。OpenStack推荐使用字符串格式,因为它更容易理解。
在策略语法中,每个规则检查都被指定为一个简单的”a:b”对形式,该”a:b”对通过匹配与之对应的类来执行检查访问权限。这些”a:b”对的类型与格式可以归纳为表1所示。
类型 | 格式 |
---|---|
用户的角色 | role:admin |
policy中定义的规则 | rule:admin_required |
通过URL检查(URL检查返回True才有权限) | http://my-url.org/check |
用户属性(可通过token获得,包括user_id、domain_id和project_id等) | project_id:%(target.project.id)s |
字符串 | ‘myproject’: |
字面量 | project_id:xpto2035abc domain_id:20 True:%(user.enabled)s |
在字符串格式的策略规则表达式中,如果需要使用多个规则,可以使用连接运算符and或or,and表示与,or表示或。下面的例子表示允许角色为admin的用户或项目ID为%(project_id)s且角色为projectadmin的用户访问。
1 | "role:admin or (project_id:%(project_id)s and role:projectadmin)" |
另外,策略规则表达式中还可以使用not运算符表取反。下面的例子表示允许项目ID为%(project_id)s且角色不是dunce的用户访问。
1 | "project_id:%(project_id)s and not role:dunce" |
在策略规则表达式中,各运算符的优先级如表2所示。其中,数字越大代表优先级越高。
优先级 | 类型 | 表达式 |
---|---|---|
4 | 组运算 | (…) |
3 | 逻辑否运算 | not … |
2 | 逻辑与运算 | … and … |
1 | 逻辑或运算 | … or … |
在列表形式的策略规则表达式中,使用”[]”表示逻辑与运算,在”[]”内的多个规则使用”,”连接,在进行权限检查时,只有”[]”中的所有规则都满足才可以通过检查;而同一级的不同”[]”表示逻辑或运算,用”,”连接,表示只要满足其中一个”[]”定义的规则即可访问;另外,使用”@”表示始终允许访问,使用”!”表示拒绝访问。基于此,上述示例表达式使用列表形式可以表示如下:
1 | [["role:admin"], ["project_id:%(project_id)s", "role:projectadmin"]] |
需要注意的是,如果一个规则定义为一个空列表[]或一个空字符串””,表示该target始终允许访问。
规则检查
在oslo.policy中,所有规则的封装与检查操作都定义在oslo_policy._checks
模块中,该模块首先定义了一个BaseCheck抽象类,所有对规则检查的封装都需要继承该抽象类。在继承BaseCheck类时,每个规则检查类都需要覆写str()方法,用于显示该检查的含义;还需要覆写call()方法,在执行具体的检查操作时通过调用具体规则检查类的call()方法实现。接下来,本文首先介绍oslo.policy中定义了规则检查类。而针对”a:b”格式的策略规则表达式,oslo.policy定义了一个继承BaseCheck类的Check类来表示,并为其定义了kind属性表示该条规则检查的类型,即a,match属性表示具体匹配的值,即b。_
GenericCheck
GenericCheck类通常用于匹配与API调用一起发送的属性。通过以下语法,策略引擎可以使用这些属性(位于策略规则表达式的右侧):
1 | user_id:%(user.id)s |
在上述语法中,右侧的值是一个字符串或者使用规定的Python字符串替换。可用的属性和值取决于使用公共策略引擎的程序。所有这些属性(与用户、API调用和上下文相关的)都可以相互检查,或对固定的常量进行检查。
GenericCheck类可以对通过令牌获取的以下几种用户属性执行策略检查:
- user_id
- domain_id和project_id(取决于token指定的范围)
- 给定的token范围内的角色role列表
特殊检查类
特殊检查类是相较于GenericCheck类而言的,特殊检查类可以提供更加灵活的检查机制。oslo.policy内置的特殊检查类包括RoleCheck、RuleCheck、HTTPCheck等。
RoleCheck类:该类用于检查提供的凭证中是否存在指定的角色。一个角色检查的表达式如下:
1
"role:<role_name>"
RuleCheck类:该类用于通过名称引用另一个已定义的规则。这样,一个普通的规则可以定义为可重用的规则,然后在其他规则中引用该规则。它还适用于将一组检查定义为一个更具描述性的命名的情况,这样便于策略的可读性。一个规则检查的表达式如下,在这个示例中,将定义好的admin_required规则进行了重用。
1
2"admin_required": "role:admin"
"<target>": "rule:admin_required"HTTPCheck类:该类用于向远程服务器发送HTTP请求,以确定检查结果。target和凭证将传递到远程服务器进行检查,如果远程服务器返回的响应结果为True,则表示该操作通过权限验证。HTTP检查的表达式如下,预期目标URL包含字符串格式的关键字,这个关键字是目标字典的key键。
1
2"http:<target URI>"
"http://server.test/%(name)s"
运算符检查类
oslo.policy为第1节中提到的各种运算符也提供了相应的检查类,主要包含以下几种检查类:
- FalseCheck类:相当于运算符”!”,即总是返回False,表示始终不允许访问;
- TrueCheck类:相当于运算符”@”,即总是返回True,表示始终允许访问;
- NotCheck类:相当于取反运算符”not …”;
- AndCheck类:相当于逻辑与运算符”… and …”;
- OrCheck类:相当于逻辑或运算符”… or …”。
除了上述的三类检查类,用户也可以自定义检查类。在自定义检查类时,首先需要继承BaseCheck类或Check类,然后覆写str()和call()方法:str()方法用于返回以此节点为根的Check树的字符串表示形式,用于打印;call()方法实现了具体的匹配算法。另外,还需要注意的是自定义检查类时还应该使用oslo_policy._checks模块下的register(name, func=None)装饰器将其缓存在检查类字典中,便于查找。
oslo.policy的权限检查实现原理
oslo.policy中权限检查的实现主要定义在oslo_policy.policy模块下。该模块中定义了用于保存规则,加载和检查规则以及定义策略的多个类。这些类的实现如下:
Rules类:该类用于缓存所有的规则,其可以直接处理default_rule的设置。该类提供了load(data, default_rule=None)和load(data, default_rule=None)可以从策略的YAML或JSON配置文件中加载所有规则;还提供了from_dict(rules_dict, default_rule=None)一个指定的字典中加载所有规则;
Enforcer类:该类负责加载和执行规则。该类提供了load_rules(force_reload=False)从该类的实例化对象绑定的策略文件路径加载所有规则,如果force_reload为True,表示从配置文件重新加载数据;提供了register_default(default)注册一个默认的RuleDefault对象,提供了register_defaults(defaults)注册一组RuleDefault对象;提供了enforce(rule, target, creds, do_raise=False, exc=None, args, \*kwargs)根据目标target和凭证检查规则的权限,该方法通常需要结合authorize(self, rule, target, creds, do_raise=False, exc=None, args, \*kwargs)装饰器使用,以保证待检查的策略规则已经被注册;该类还提供了check_rules(raise_on_violation=False)检查是否存在明显不正确的规则,如未定义的规则或循环引用的规则等。
RuleDefault类:该类用于定义一个权限检查策略,创建时需要指定名称name和值check_str,建议对该策略定义一个详细的说明description;
DocumentedRuleDefault类:该类用于定义一个policy-in-code的策略对象。该类的功能与RuleDefault类似,但它还需要一些与注册的策略规则有关的额外的数据。这样就可以根据这个类的属性来呈现与之对应的文档。最终,oslo.policy都会使用该类而弃用RuleDefault。创建该类的对象时,必须指定名称name、值check_str、描述信息description;另外,还需要定义一个operations属性,这个属性包含了每个API的URL和相应HTTP请求方法的字典。下面是一个operations属性的示例。
1
2operations=[{'path': '/foo', 'method': 'GET'},
{'path': '/some', 'method': 'POST'}]DeprecatedRule类:该类主要用于表示一个被废弃的策略或规则。
oslo.policy的使用方法
本节结合上面的内容以及nova组件介绍oslo.policy的使用方法。一般地,OpenStack其他组件可以直接使用oslo.policy库实现RBAC策略,也可以对oslo.policy库进行扩展,实现适合自身使用的RBAC策略。nova组件就是对oslo.policy的实现进行了扩展。
首先为了实现nova自身的需求,nova组件实现了一个检查类。
1 |
|
这个类用于判断用户是否是admin用户。接着,nova组件实现了一个初始化方法init()。
1 | from oslo_config import cfg |
该初始化方法创建了一个Enforcer对象,并将所有策略规则都加载到缓存中备用。然后,nova组件分别定义了两个用于检查规则的方法。
1 | def authorize(context, action, target, do_raise=True, exc=None): |
其中,authorize()方法对oslo.policy中的所有默认规则进行检查;而check_is_admin()方法只对nova自定义的IsAdminCheck类的规则进行检查。紧接着,nova组件定义了一个用户获取Enforcer对象的方法。
1 | def get_enforcer(): |
该方法通过读取配置文件或输入参数中的相关配置信息,获取一个Enforcer对象。因此,为了实现oslo.policy的功能,需要在nova组件的配置文件中添加如下的配置信息:
1 | [DEFAULT] |
其中,namespace为oslo.policy添加了一个命名空间,这样可以隔离OpenStack的不同组件;output_file为默认策略规则文件的输出路径,当然你也可以自定义一个策略规则文件。
如果需要为定义的Enforcer对象添加RuleDefault对象,则可以使用如下的方式。首先,创建一个Enforcer对象,然后创建一个或多个RuleDefault对象,接着调用Enforcer对象的register_defaults()方法或register_default()方法将RuleDefault对象注册到Enforcer对象中。
1 | from oslo_config import cfg |
最后,为了可以使用oslo.policy相关的命令行更好的管理权限策略规则,可以在nova组件安装配置文件setup.cfg文件中进行添加如下配置:
1 | [entry_points] |
这样,在使用命令行管理nova组件的权限控制策略时,便可以根据oslo.policy.enforcer配置项找到nova组件的Enforcer对象。
原文链接:https://blog.csdn.net/Bill_Xiang_/article/details/78665544