Barbican 訪問控制

基於角色的訪問控制 Role Based Access Control (RBAC)

像大多數其餘openstack服務，Barbican經過定義一個權限文件，來支持對API的訪問控制。這個文件在配置文件/etc/barbican/barbican.conf中指定，通常狀況下存儲在/etc/barbican/policy.json

 

每個barbican的API在該文件中都有對應的一行權限聲明，格式以下：

API_NAME: RULE_STATEMENT or MATCH_STATEMENT

 

API_NAME: 對應的API

RULE_STATEMENT：多是其餘的RULE_STATEMENT或者一個MATCH_STATEMENT

MATCH_STATEMENT: 是一組標識符，必須在API的調用者提供的token 和 該API的參數或目標實體之間匹配

例如：

"secrets:post": "role:admin or role:creator"

表明要經過post方法建立新密鑰，必需要是admin角色，或者是creator角色

 

注意：

密鑰管理服務通常是基於項目範圍，對密鑰進行管理，這意味着不少API調用會額外檢查密鑰所屬的project_id是否匹配調用者所屬的project_id。

 

 

默認的權限

openstack的policy引擎很是靈活，並且能夠自定義。barbican服務默認提供了5種角色：

 

key-manager:service-admin

密鑰管理服務的管理員，該角色下的用戶能夠訪問全部的管理API，如project-quotas

 

admin

項目管理員，該角色下的用戶有對本身所屬項目下全部資源的訪問權限

 

creator

創造者，該角色下的用戶可以建立新的資源，而且只能刪除本身建立的資源，不能刪除其餘用戶建立的資源。該用戶能訪問本項目下全部存在的secrets

 

observer

觀察者，該角色下的用戶容許訪問存在的密鑰，可是不能建立、更新、刪除密鑰。

 

audit

審計員，該角色下的用戶只能訪問密鑰的metadata，不能解密密鑰。

 

 

Access Control List API

除了以上的基於角色的權限控制，barbican還提供ACL API來更細粒度的控制訪問權限。

ACL API是配置在具體的secret上或者container上。

 

當前版本只定義了「read」操做的ACL API。

 

若是一個secret配置了ACL，只有在ACL列表裏的user，才能對該secret進行讀取或解密操做。

同理，若是一個container配置了ACL，只有在ACL列表裏的user，才能對該container中的secret進行讀取或解密操做。

備註：container是secret的容器。

 

ACL容許把secret或container標記爲私有。私有的secret或container意味着只有secret或container的建立者才能獲取和解密secret，其它用戶沒法獲取和解密。若要容許其它用戶訪問，須要把用戶ID加到ACL user列表裏。

 

ACL有以下屬性：

users: 容許訪問資源的用戶白名單。

project-access: 標示該secret／container是不是私有。true: 非私有，false：私有

 

爲了完成對secret／container的權限管理，單單隻有acl數據填充是不夠的。

如下ACL規則在資源訪問策略中定義並進行「OR」操做：

• 當token用戶（即調用API的用戶）存在於secret／container的user列表中時，容許基於ACL的訪問。
• 當secret／container標記爲私有，此時project級別的RBAC user不容許訪問。

 

注意：

目前barbican只定義了「read」操做的ACL規則，所以只有對secret和container的GET操做會匹配ACL規則，其它操做仍然採用project級別的RBAC策略。

 

疑問：若是project-access設置成true，不在users列表中的user訪問，會是什麼狀況？

 

只有admin角色或creator角色的用戶，能管理該secret／container的ACL規則。

 

默認ACL

當建立一個secret／container時，會有個默認規則，即資源是非私有的，而且沒有user在ACL列表裏。

{   "read":{     "project-access": true   } }