将获取解密后的密钥更改为唯一的 URI¶
包含您的 Launchpad 蓝图的 URL
https://blueprints.launchpad.net/barbican/+spec/api-change-get-secrets-decrypted
当前，检索存储在 Barbican 中的密钥的元数据和实际解密后的数据使用相同的 URI，仅通过 Accept 标头来确定返回哪个响应。这使得在 Barbican 前面部署具有 RBAC 系统的部署（例如 Repose - http://openrepose.org/）或作为中间件（例如 EOM - https://github.com/racker/eom）变得复杂。它还需要在 Barbican 应用中使用类似以下的逻辑来强制执行 RBAC：https://github.com/openstack/barbican/blob/master/barbican/api/controllers/__init__.py#L53
此蓝图建议使用唯一的 URI 来访问解密后的密钥，例如：<host>/v1/secrets/<secret-UUID>/payload
问题描述¶
当前，要检索密钥的元数据及其解密后的数据，使用相同的 URI，例如
GET <host>/v1/secrets/<secret-UUID>
如果通过 URI 区分这两种检索类型，则配置在 Barbican 部署前面运行的 RBAC 系统将会更容易。
提议的变更¶
此蓝图要求添加一个新的 URI 结构来检索解密后的密钥，如下所示
GET <host>/v1/secrets/<secret-UUID>/payload
因此，这将包括添加一个新的 Pecan 子控制器来处理“payload”请求，添加新的“payload”资源的单元和功能测试，以及更新 API 文档。
在当前的“v1”API 版本中，现有的基于 Accept 的解密方法将不会被删除，以避免破坏当前的 API 合同，但可以在 API 的下一个版本（“v2”）中删除（不属于此蓝图）。
备选方案¶
另一种选择是使用如下 URI 来检索解密后的密钥
GET <host>/v1/secrets/<secret-UUID>.payload
但是，这种方法需要在 Pecan 控制器逻辑中进行解析。
数据模型影响¶
无
REST API 影响¶
此蓝图将添加一个新的 URI 来检索解密后的密钥
GET <host>/v1/secrets/<secret-UUID>/payload
Accept 标头仍然会像现在一样用于指定返回解密密钥所需的格式，但不再需要/使用“application/json”格式。
检索密钥的当前 URI 仍然像现在一样工作，但解密选项可以在 API 的下一个版本（“v2”）中通过未来的蓝图删除。
安全影响¶
没有，因为将使用与当前基于标头的解密机制相同的策略规则（“secret:decrypt”）用于新的解密操作。
通知与审计影响¶
没有，但由于此蓝图采用的每个操作一个唯一 URI 的方法，审计实际上可能会更容易。
其他最终用户影响¶
Python Barbican 客户端也需要更新以配合此更改。
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
拟议的更改将清理 Pecan 控制器代码，将密钥元数据和解密后的有效负载问题从彼此分离。
实现¶
负责人¶
- 主要负责人
jaosorior
- 其他贡献者
john-wood-w
工作项¶
在“secrets”资源上添加新的“payload”子资源控制器，使用“secret:decrypt”策略操作
添加相关的单元和功能测试，如下所示
更新 API 文档，如下所示（当前位于此处：https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface）
更新 Python Barbican 客户端以使用此新资源。如果不可用（由于较旧的 Barbican 部署），它应回退到使用当前的解密模式
依赖项¶
无
测试¶
添加单元和功能测试，以测试使用“secrets”资源上的新“payload”资源检索解密后的密钥。这些新测试应在 Devstack gate 作业中正常工作。
文档影响¶
需要更新 API 文档以反映这些新的密钥解密 API 调用，并标记当前基于 Accept 标头的方案为“已弃用”。
参考资料¶
无
