【openstack】Nova中的policy

Nova中的policy

本博客欢迎转发，但请保留原作者信息！内容系本人学习、研究和总结，如有雷同，实属荣幸！

任何对外暴露接口的系统，都必须有分权分域以及认证鉴权的功能。在openstack中，keystone组件用来对用户进行认证，说白了就是看用户是否是系统的合法用户，而policy机制则主要看用户的操作是否满足特定的条件，比如一些接口是特权接口（仅限管理员使用），普通用户不允许调用。下面以Nova中创建虚拟机为例，讲述Nova中policy机制的原理。

在nova.compute.api.API::create()函数中:

<!--[endif]-->

_check_create_policies函数就是完成校验的工作。

首先，policy.json文件预定义了不同操作的策略，目前有三种类型策略，rule类型，role类型，generic类型。1.rule定义了一些要从文件中读取的规则，比如rule:admin_or_owner，admin_or_owner的定义内容需要再从文件中读取。

2.role定义了基于用户身份(context[‘roles’])的规则，比如role:admin，要求只有admin用户才能匹配成功。

3.generic类型基于参数，比如project_id:%(project_id)s，其中%(project_id)是通过参数中的字典传递进来的，然后会与context中的project_id作比较。而is_admin:True则是直接将True与context中is_admin的值作比较。

举个例子：

"admin_or_owner": [["is_admin:True"], ["project_id:%(project_id)s"]],

"compute:create": [["rule:admin_or_owner"]],

这是定义创建虚拟机操作的策略。表示只有admin或tenant内的用户可以进行创建虚拟机操作。

其次，每次进行判断前，都会对policy.json文件进行读取，如果文件相对前一次读取没有改变，则直接从缓存中获取文件内容，否则重新读取文件内容。这也是Nova支持动态策略的原因，即可以根据需要动态的修改policy.json的内容，而不需要重启进程即可让策略生效。

貌似Quantum中的policy机制与Nova类似，在Quantum Admin Guide中的Authentication and Authorization章节也有阐述。大家可以作为参考。

PS： 新手初学，不严谨或不正确的地方，望各路大神指正！