为允许存储私有密钥添加每个密钥策略¶
https://blueprints.launchpad.net/barbican/+spec/add-per-secret-policy
问题描述¶
这是添加每个密钥策略（add-per-secret-policy）规范的配套规范。该规范提出了一种机制，允许密钥项目之外的用户访问密钥/容器。这种机制涉及在数据库中存储每个密钥/容器的访问控制数据。
本规范解决了相关问题。目前，具有密钥创建者项目中相关角色的所有用户都可以访问密钥。这意味着同一项目的所有成员都可以访问为该项目存储的所有密钥。
最近，有请求能够指定“私有密钥”。这些密钥只能由密钥创建者（创建密钥的用户）提取。
现在，可以为希望存储私有密钥的每个用户创建一个项目。这似乎是一个非常繁重的解决方案，在管理所有必需的组和角色方面有很大的管理开销。
提议的变更¶
提案是为每个密钥/容器存储额外的访问数据。此数据（“creator_only”，值为 True/False）将作为单独的列存储在 SecretACL 和 ContainerACL 数据表中。详细信息请参阅下面的“数据模型影响”部分。
当访问密钥/容器时，creator_only 信息和任何白名单信息通过 target.* 变量传递给策略层。然后通过评估使用这些参数的策略规则来确定访问权限。建议的策略规则在下面的“策略”部分中指定。
最后，需要增强 REST API，以允许用户指定和更改密钥/容器的 creator_only 状态。
操作¶
当 creator_only = True 时，许多不同的操作受到限制
- 获取：如果 creator_only 为 true，则只有密钥/容器的创建者才能
访问密钥。但限制对容器的访问不会将限制级联到组成密钥。
请注意，这不影响已明确允许获取密钥/容器的白名单用户。
- 删除：如果 creator_only 为 true，则密钥/容器只能由
创建者删除。
- 写入：如果 creator_only 为 true，则密钥/容器只能由
创建者删除。
change-acl：默认情况下，这只能由创建者修改。
- 列表：如果 creator_only 为 true，则只有创建者才能列出密钥。
这意味着如果非创建者访问 GET /secrets，则不会显示密钥的链接
数据模型影响¶
根据每个密钥规范，密钥、容器和订单表将添加一列来存储密钥的创建者。该列将由创建者的 user_id 填充。
需要向 ContainerACL 和 SecretACL 表添加一个布尔列（“creator_only”）。ACL 表的字段如下：
secret_id：指向 Secrets 表的外键 operation：（在本例中为 get, write, delete, list） users：字符串，指定操作的白名单用户列表 creator_only：True/False
当一个密钥被指定为“creator_only”时，将创建/修改几个字段
secret_id : get : users, True
secret_id: write: None, True
secret_id: delete: None, True
secret_id: list: None, True
将密钥取消指定为“仅限创建者”将修改/删除上述条目。
REST API 影响¶
将一个新参数（“creator-only”），其取值为“True”和“False”，添加到 ACL 定义中。它将默认为 False。因此，ACL 定义将如下所示：
{ "get": { "users": ["some_user", "another_user"], }, "creator-only": "true" }
如果 creator-only 设置为 true，将创建上面提到的字段。
如每个密钥规范中所述，ACL 可以作为可选的 acl 参数在使用 POST 请求创建密钥时指定。它也可以通过 GET 或 POST 进行检索或修改。
POST <host>/v1/secrets/<secret-UUID>/acl GET <host>/v1/secrets/<secret-UUID>/acl
策略¶
当访问容器或密钥时，ACL 数据将从数据库中检索，并作为 target.* 属性提供给 RBAC 层。例如，为了读取密钥，我们可以传入 target.user_whitelist 和 target.creator_only。
策略规则将如下所示：
(can_read_shared and user_in_user_whitelist) OR
((current_resource_permissions and not creator_only) OR user_is_creator)
(current_resource_permissions) 部分基本上表示用户在密钥创建者的项目中具有相关角色。
对于删除、修改等操作，规则要简单得多，因为我们不需要考虑白名单。例如，删除可能看起来像这样：
((current_resource_permissions and not creator_only) OR user_is_creator)
备选方案¶
如前所述，对于私有密钥，我们可以为每个用户创建一个组。除了繁琐之外，这还会给系统管理员带来维护负担，以跟踪新增和删除的用户。
安全影响¶
通过允许用户指定私有密钥，这提高了整个堆栈的安全性与可用性。
通知与审计影响¶
无。
其他最终用户影响¶
python-barbicanclient 将需要更新，以提供用于填充额外参数的接口。
性能影响¶
访问密钥/容器将需要两次数据库调用：一次是作为 RBAC 引擎规则执行的一部分获取密钥/容器白名单，另一次是实际获取密钥。
这两个数据库访问在逻辑上是分开的，因为第一个过程由中间件控制，第二个由 Pecan 控制。我们可能能够利用相同的 SQLAlchemy 事务，或者缓存该密钥实体数据供控制器使用，因此这可能没有争议。
其他部署者影响¶
无。
开发人员影响¶
无。
实现¶
负责人
- 主要负责人
alee rm_work
工作项¶
向数据库表添加新字段，并向 REST API 添加新参数/调用。
添加逻辑以解析数据并将数据存储在数据库中。
添加逻辑以从数据库中检索数据，并将其作为 target.* 属性提供给 RBAC 层。
根据这些 target.* 属性修改策略规则。这里可能需要扩展 oslo 策略以考虑新的布尔标志。任何更改都需要清楚地传达给部署者，因为不能保证他们会使用默认策略文件进行部署。
依赖项¶
无
测试¶
当前的单元测试也将被修改以反映此更改。
文档影响¶
Barbican 文档和 API 文档将需要更改。
