基于角色的访问控制 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
}
}
"read":{
"project-access": true
}
}