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   } }