深度好文,值得一看,原文链接如下:
http://blog.csdn.net/hackerain/article/details/8241691
1. 首先还是先来了解一下什么是policy,它是用来做什么的
在openstack的用户管理中,有三个概念:Users, Tenants, Roles。简单来说,policy就是用来控制某一个User在某个Tenant中的权限的。这个User能执行什么操作,不能执行什么操作,就是通过policy机制来实现的。直观的看,policy就是一个json文件,位于/etc/[SERVICE_CODENAME]/policy.json中,每一个服务都有一个对应的policy.json文件,通过配置这个文件,实现了对User的权限管理。
另外就是还有一个角色(role)的概念,这个概念肯定都很熟悉了,是权限的集合,可以将role赋予某个user,使这个user拥有相应的权限,方便用户权限管理。policy.json文件可以在role的级别配置,不过默认的配置的角色只有admin,如果需要配置其他的角色,需要自己创建,然后在policy.json中进行配置。
接下来,看一下policy.json长什么样子:
- {
- "context_is_admin": "role:admin",
- "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
- "default": "rule:admin_or_owner",
- "compute:create": "role:admin",
- "compute:create:attach_network": "",
- "compute:create:attach_volume": "",
- "compute:create:forced_host": "is_admin:True",
- "compute:get_all": "",
- ......
- }
policy.json有两种写法,一种是每一行写成列表形式的,另一种就是上面的例子,是写成字符串形式的,这里只说后面一种情况。
每一行可以分为两部分:冒号前面的叫做action,即用户执行的操作,冒号后面的叫rule,即用来根据当前的上下文(context),来判断前面的action是否能够由当前的user执行。policy做的主要工作,就是来解析这个rule的,要把这个字符串的rule,解析成相应的对象,在外部调用policy进行权限认证的时候,根据action映射到相应的rule对象,然后由这个对象判断是否能够执行这个action。
但是如上面的例子,像context_is_admin,admin_or_owner这样的action,怎么看都不像action,它们的确不是action,后面会讲到是怎么回事。
这部分功能的实现主要在nova/openstack/common/policy.py模块中实现,首先还是先来看看这个模块的整体结构图:
首先就是那个Rules类,它继承自dict,也就是说Rules是一个字典类型的,它的对象就是保存解析之后的policy.json文件得到的数据的,key保存的是action,value保存的是解析rule得到的对象。这个Rules对象被创建后,会赋值给模块中的_rules变量。
其次是BaseCheck体系类,它们就对应的是rule字符串解析之后得到的对象,即Rules对象的value保存的就是BaseCheck对象。这个类体系可以分为三类:
1)TrueCheck和FalseCheck:解析他们是最简单的,rule如果是空字符串或者是"@"的话,那么就直接对应的是TrueCheck对象,这个对象的返回值总为True;如果rule是"!"的话,那么就对应FalseCheck对象,总是返回False,如果rule不对应任何对象,那么它就最终对应FalseCheck对象
2)RuleCheck, RoleCheck, HttpCheck, GenericCheck:rule字符串中,冒号左边是"rule"的,都会解析成RuleCheck对象,冒号左边是"role"的都会解析成RoleCheck,冒号左边是"http"的都会解析成RoleCheck对象,如果是其他的情况,那么就对应GenericCheck对象,比如rule为is_admin:True的情况。
3)OrCheck, AndCheck, NotCheck:这些对象对应的是复合的rule,即用逻辑符号连接的几条规则,比如上面例子中的"is_admin:True or project_id:%(project_id)s",它对应的对象为OrCheck类型。上面两种情况的解析都很简单,难的就是这个复合rule的解析,费了一番功夫。上面类图中的ParseState类和ParseStateMeta类就是用来解析复合rule的。
如果不深究每条rule是怎么解析的话,看一个函数就够了,即模块中的_parse_check()函数,从这个函数中,就可以知道每条规则对应哪种对象:
- # 真正的解析一个单一的rule,将它由冒号分隔开,得到kind和match,根据kind值,在_check查找对应的Check对象,
- # 然后以kind,match为参数,调用Check对象的__call__()返回最终的结果:真或假
- def _parse_check(rule):
- """
- Parse a single base check rule into an appropriate Check object.
- """
- # Handle the special checks
- if rule == '!':
- return FalseCheck()
- elif rule == '@':
- return TrueCheck()
- try:
- kind, match = rule.split(':', 1)
- except Exception:
- LOG.exception(_("Failed to understand rule %(rule)s") % locals())
- # If the rule is invalid, we'll fail closed
- return FalseCheck()
- # Find what implements the check
- if kind in _checks:
- return _checks[kind](kind, match)#这里竟然调用的是Check的__init__(),把kind和match赋值给Check中的kind和match
- elif None in _checks:
- return _checks[None](kind, match)
- else:
- LOG.error(_("No handler for matches of kind %s") % kind)
- return FalseCheck()
最后,再来说一下转换成的这些对象有什么用,为什么要费这么大劲转换成对象,直接用字符串的rule来判断不好吗,以及怎么用这些对象去判断用户的操作是否合法?
为什么要将字符串转换成对象?这个理由太好说了,就是为了抽象,抽象是为了方便,是为了以不变应万变,这就是面向对象的好处。比如此处的Check对象,就抽象出了kind和match成员变量,分别对应rule字符串的冒号左边和右边的内容。当用这些对象来判断用户操作是否合法时,是这样来使用的:result = _rules[action](target, creds),因为Rules类被创建后会赋值给_rules变量,所以这里的_rules变量就代表Rules对象,而Rules对象又是一个字典类型的,key是action,value是BaseCheck对象,所以就相当于是直接在调用BaseCheck对象的__call__()方法了,参数分别是target和creds,target是action要操作的目标,creds是当前的上下文环境,再结合Check对象中的kind和match,就可以根据相应的逻辑来判断这个操作是否合法了。举个简单的例子,看RoleCheck是如何来判断的:
- @register("role")
- class RoleCheck(Check):
- def __call__(self, target, creds):
- """Check that there is a matching role in the cred dict."""
- return self.match.lower() in [x.lower() for x in creds['roles']]
比如规则"role:admin",kind为"role",match为"admin",所以RoleCheck就是判断一下admin这个用户是否在creds上下文中,如果在,就返回真,不在返回假。
至于OrCheck等对象判断是否合法则更简单,在他们内部都维护了一个rules列表,存放的是每条单一规则对应的Check对象,在他们的__call__()方法中一个for循环,来判断,OrCheck为一真即真,AndCheck为一假即假。
上面还提到有些action看起来不像action的,的确,那样的规则,一般都会转换成GenericCheck对象,而RuleCheck对象的__call__()在判断用户操作是否合法时,是采用递归的方法来判断的,比如下面的例子:
- "compute_extension:accounts": "rule:admin_api", #-->RuleCheck
- "admin_api": "is_admin:True", #-->GenericCheck
3. 如何使用
如何使用上面已经说的差不多了,在外部只要调用nova/policy.py模块中的enforce()即可:
- def enforce(context, action, target, do_raise=True):
- init()#读取json文件,解析,并将解析的内容封装成一个Rules对象,然后把这个对象赋值给_rules变量
- credentials = context.to_dict()
- extra = {}
- if do_raise:
- extra.update(exc=exception.PolicyNotAuthorized, action=action)
- return policy.check(action, target, credentials, **extra)
4. 测试
说了这么多,不能光说不练啊,这里还是举个创建实例的例子,通过调试的手段,来具体看一下效果。测试的过程如下:
(1)修改程序
在nova/compute/api.py中的_check_create_policies()方法中添加如下几句代码:
- print '*'*30
- creds=context.to_dict()
- print creds['roles']
- print '*'*30
- raise Exception
(2)启动各项服务
(3)修改policy.json文件
将 "compute:create" : "" 这条规则修改为:"compute:create": "role:admin", 即将原来的任何角色的用户都可以创建实例的权限修改为只有admin角色的用户可以创建实例。
(4)创建实例,观看异常
- $ source openrc demo demo
- $ nova boot --flavor 1 --image 29936f2a-0e05-47e0-8d43-b9d579b107f9 --key-name pubkey-01 instance-01
- ERROR: Policy doesn't allow compute:create to be performed. (HTTP 403) (Request-ID: req-bd0cda7e-2207-46af-becb-72a3a3bec598)
看下日志中输出的当前上下文中的角色:
******************************
[u'Member', u'anotherrole']
******************************
如果使用admin角色的用户创建实例是没有问题的。日志输出如下:
******************************
[u'admin', u'KeystoneAdmin', u'KeystoneServiceAdmin']
******************************