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