openstack policy机制
一、什么是policy
policy策略,是OpenStack用來約束不同等級用戶的操作權(quán)限,用于自定義權(quán)限管理的一種機制。
?
二、為什么要用policy
1、基于keystone理解policy
Keystone中有User(用戶)、Project(租戶)、role(角色)三個概念,使用基本流程為:
1)創(chuàng)建租戶 2)創(chuàng)建用戶 3)創(chuàng)建角色 4)給用戶和租戶賦予角色
賦予角色之后,角色還只是一個空的概念定義,沒有實際意義。真正限制用戶角色執(zhí)行具體action操作的,是policy.json文件。
?
Keystone使用基于角色的訪問控制(RBAC)保護其API。用戶根據(jù)他們具體的角色,才可以訪問不同的API。
OpenStack各組件下都有對應(yīng)的policy.json,每一個模塊通過各自的policy.json文件對Role進行訪問控制,為其定義API訪問策略,來確定哪個用戶可以以哪種方式訪問??哪些對象。
當(dāng)對OpenStack服務(wù)進行API調(diào)用時,服務(wù)的策略引擎就會使用適當(dāng)?shù)牟呗远x來確定是否可以接受該調(diào)用,策略規(guī)則確定在什么情況下允許API調(diào)用。
因此,當(dāng)定制需求需要新增api接口時,需要在組件對應(yīng)的policy.json中,添加對應(yīng)API接口的權(quán)限控制。
?
policy.json文件會立即生效,不需要重新啟動服務(wù)。云管理員可以修改或更新這些策略,以控制對各種資源的訪問。
用戶角色和權(quán)限的關(guān)系,參考RBAC相關(guān)描述:http://www.woshipm.com/pd/1150093.html
?
2、舉例理解policy
某公司通過RBAC做權(quán)限管理,場景如下
用戶:員工張三、管理者李四、老板王五、人力趙六
租戶:研發(fā)部、銷售部、財務(wù)部
角色:程序員、技術(shù)總監(jiān)、老板、人力
action:增、刪、改、查部門信息;? 增、刪、改、查員工信息; 查看公告信息; 訪問門禁系統(tǒng)等等
?
policy.json中可以定義以下內(nèi)容:
普通員工只能查詢自己信息,老板可以對所有員工信息增刪改查。
老板可以新增一個部門、刪除一個部門,員工就不可以。
所有人都可以訪問門禁系統(tǒng)。
員工只能使用部門內(nèi)部的資源,類似租戶資源隔離。
?
policy.json文件可以理解為一份權(quán)利清單,里面描述了不同的角色分別可以做哪些事情。例如:
{"is_boss": "role:boss","is_leader": "role:leader","is_employee": "role:employee","is_hr": "role:hr","company_all_members": "rule:is_boss or rule:is_leader or rule:is_hr or rule:is_employee","boss_or_leader_or_hr": "rule:is_boss or rule:is_leader or rule:is_hr","employee:list": "rule:boss or rule:is_hr or leader_id:%(leader_id)s","employee:show": "rule:boss_or_leader_or_hr or rule: employee_id:%(employee_id)s","employee:create": "rule:is_hr","employee:update": "rule:is_hr or rule: employee_id:%(employee_id)s","employee:delete": "rule:is_hr","department:list": "rule:company_all_members","department:show": "rule:company_all_members","department:create": "rule:is_boss","department:update": "rule:is_leader","department:delete": "rule:is_boss","access_control_card: get_token": "company_all_members""company_notice:show": """no_released_message:show": "!"}三、怎么用policy約束權(quán)限
policy.json基于JSON文本格式,使用白名單機制進行過濾,每個策略由單行語句定義。
?
1、policy.json位置
位于每個OpenStack組件的配置文件中,/etc/$component_name/policy.json
例如:# ls /etc/nova/policy.json
?
2、policy.json文件整體格式
policy.json文件由target:rule或alias:definition形式的策略和別名組成,并用逗號分隔并用花括號括起來:
{
"alias 1" : "definition 1",
"alias 2" : "definition 2",
...
"target 1" : "rule 1",
"target 2" : "rule 2",
....
}
?
3、target格式
target即指定的API,可以寫為"service:API"或簡稱為"API". 例如,"compute:create"或"add_image"
?
4、rule格式
rule決定是否允許API調(diào)用。
rule規(guī)則可以是:
1)始終允許該操作,可以寫為""(空字符串),[]或"@",一般為空字符串即可
2)始終不允許該操作,寫成"!"
3)兩個值的比較,例如檢查project_id是否匹配,若匹配才可以調(diào)用。
(a) 常量:字符串,數(shù)字,true,false
(b) API屬性,可以是project_id,user_id或domain_id
(c) 目標(biāo)對象屬性,即數(shù)據(jù)庫中對象描述中的字段. 例如,對于"compute:start" API,對象是要啟動的實例. 啟動實例的策略可以使用%(project_id)s屬性,即擁有實例的項目。尾隨s表示這是一個字符串。
(d) is_admin標(biāo)志位,表示管理特權(quán)是通過admin令牌機制( keystone命令的--os-token選項)授予的. 管理員令牌允許在存在管理員角色之前初始化身份數(shù)據(jù)庫.
4)基于簡單規(guī)則的布爾表達式,例如,使用not限制指定限制范圍
5)特殊檢查
(a) role:<role name> 指定角色來定義規(guī)則,例如:"deny_stack_user": "not role:heat_stack_user",deny_stack_user這個rule規(guī)則就表示,所有不是heat_stack_user角色的用戶
(b) rule:<rule name> 定義rule規(guī)則別名, 例如:"stacks:create": "rule:deny_stack_user",其中deny_stack_user即為上一步定義的別名
(c) http:<target URL> 將檢查委托給遠程服務(wù)器. 服務(wù)器返回True時,將授權(quán)該API
?
5、alias別名
別名構(gòu)造是為了方便起見. 別名是復(fù)雜或難以理解的規(guī)則的簡稱. 它的定義與策略相同
格式如下:
alias name : alias definition
定義別名后,請使用rule關(guān)鍵字在策略規(guī)則中使用它.
?
6、常用規(guī)則舉例
1)rule為"",表示允許all通過
"compute:get_all" : ""
目標(biāo)是Compute服務(wù)的"列出所有實例" API "compute:get_all" . 規(guī)則是一個空字符串,表示"始終". 此策略允許任何人列出實例.
2)rule為"!",表示拒絕使用API??的權(quán)限,用于禁用某個API調(diào)用
"compute:shelve": "!"
3)rule為"role:admin",表示此API只能由管理員調(diào)用
"identity:create_user" : "role:admin"
此策略確保只有管理員才能在Identity數(shù)據(jù)庫中創(chuàng)建新用戶
4)使用運算符not,and,or和括號構(gòu)建更復(fù)雜的規(guī)則
"stacks:create": "not role:heat_stack_user"
具有heat_stack_user角色的任何人都不能使用heat創(chuàng)建stack
5)用別名定義角色role,規(guī)則rule指向role別名
定義別名:
"deny_stack_user": "not role:heat_stack_user"
policy解析時,會分析到"deny_stack_user"不是API,因此將其解釋為別名.
此時,禁止heat_stack_user角色使用heat創(chuàng)建stack,也可指定如下:
"stacks:create": "rule:deny_stack_user"
6)將API屬性與對象屬性進行比較
"os_compute_api:servers:start" : "project_id:%(project_id)s"
指出只有實例的所有者才能啟動它. 冒號之前的project_id字符串是API屬性,即API用戶的項目ID. 它將與對象的項目ID(在這種情況下為實例)進行比較. 更準(zhǔn)確地說,將其與數(shù)據(jù)庫中該對象的project_id字段進行比較. 如果兩個值相等,則授予權(quán)限.
?
四、policy代碼實現(xiàn)
以nova創(chuàng)建虛機為例說明。
1、nova\compute\api.py
? ? def create()方法,調(diào)用 _check_create_policies
?? ?_check_create_policies() 調(diào)用 check_policy()
2、 nova\policy.py
?? ?def enforce()方法,首先 init() 初始化Enforcer類對象_ENFORCER,此時傳入use_conf為True,表示初始化操作時,需要讀取policy配置文件。
?? ?初始化之后,調(diào)用對應(yīng)的enforce方法
3、 nova\openstack\common\policy.py
? ? 直接調(diào)用Enforcer類的def enforce(), 調(diào)用load_rules()
4、 nova\openstack\common\fileutils.py
? ? read_cached_file() 方法讀取policy文件屬性,如果修改時間變更,則認為有修改,則重新加載讀取policy配置文件。
? ? policy支持動態(tài)策略,無須重啟服務(wù),主要由此方法實現(xiàn)
def read_cached_file(filename, force_reload=False):"""Read from a file if it has been modified.:param force_reload: Whether to reload the file.:returns: A tuple with a boolean specifying if the data is freshor not."""global _FILE_CACHEif force_reload:delete_cached_file(filename)reloaded = Falsemtime = os.path.getmtime(filename)cache_info = _FILE_CACHE.setdefault(filename, {})if not cache_info or mtime > cache_info.get('mtime', 0):LOG.debug("Reloading cached file %s" % filename)with open(filename) as fap:cache_info['data'] = fap.read()cache_info['mtime'] = mtimereloaded = Truereturn (reloaded, cache_info['data'])?參考調(diào)用圖:
?
參考:
https://docs.openstack.org/oslo.policy/latest/admin/policy-json-file.html
https://www.iteye.com/blog/lynnkong-1722172
?
?
?
總結(jié)
以上是生活随笔為你收集整理的openstack policy机制的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: hover和active的区别
- 下一篇: CV中domain adaptation