重构项目以更好地适应所有插件类型¶

包含您的 Launchpad 蓝图的 URL

https://blueprints.launchpad.net/barbican/+spec/restructure-for-plugins

当前项目结构只在“crypto”包中自然地适应 HSM 风格的插件。本蓝图通过在“plugin”包下重组项目结构来适应 Barbican 所需的所有插件类型。

问题描述¶

当前项目结构将 Barbican 目前唯一支持的插件（用于与 HSM 接口）放置在“crypto”包中。对新的 Barbican 功能的规划揭示了对新类型插件的需求，这些插件要么难以使用 HSM 契约实现（例如 Dogtag 或 KMIP），要么是完全不同类型的插件。后者包括 SSL 证书工作流处理插件和事件插件。这些新插件不适合当前的“crypto”包，因此 Barbican 已经超出了其范围。

提议的变更¶

本蓝图将当前的“crypto”包替换为以下包结构：

common/

resources.py - API 和 Worker 进程调用此模块以: 生成、存储或获取机密。
plugin_managers.py - 包含基础级别的 stevedore 插件查找逻辑，根据需要。: 由 plugin 包中的接口扩展。

plugin/

interface/ - 存储其他 Barbican 包使用的插件契约

（作为 abc 抽象）。还包含 stevedore 查找方法。

secret_store.py - Nate 当前的数据存储插件，用于
安全地存储/检索机密（例如 Dogtag 和 KMIP）。还将包括一个名为 SecretStorePluginManager 的类，它使用 stevedore 来查找 Nate 的机密存储插件实现。

certificates.py - SSL 证书工作流插件。还将包括一个
名为 CertGenerationPluginManager 的类，它使用 stevedore 来查找证书生成工作流插件实现。

crypto/ - 类似于当前的“crypto”包。存储

HSM 和安全模块相关模块。由于这是一个不打算从插件包外部调用的“内部”接口，这些模块与上述“interface”包是隔离的。

crypto.py - 用于 HSM 风格接口的密钥和机密生成插件。
类似于当前的 crypto/plugin.py::CryptoPluginBase 接口。还将包括一个名为 SecretGenerationPluginManager 的类，它使用 stevedore 来查找对称/非对称密钥生成插件（即所谓的“第二级插件查找”）。此逻辑与当前的 crypto/extension_manager.py 非常相似。

p11_crypto.py - Paul 的 HSM 插件实现。

simple_crypto.py - 安全模块插件的简单实现。

store_crypto.py - secret_store.py 的实现，用于在高层 secret_store.py 接口和低层 crypto.py 接口之间进行适配。
将利用 SecretGenerationPluginManager 来定位“第二级”HSM 风格的插件实现。

dogtag.py - secret_store.py 接口的 Dogtag 实现。

kmip.py - secret_store.py 接口的 KMIP 实现。

symantec.py - certificates.py 接口的赛门铁克实现。
接口。

这项工作首先只引入新结构。然后将现有插件转移到新结构中，并验证单元测试仍然通过。

为了为这个新结构提供具体上下文，以下序列提供了一个在这次重构工作后存储机密的示例流程：

调用 POST /secrets（使用一步法）
barbican.api.controllers.secrets.py 中的 API 代码调用...
barbican.common.resources.py 中的通用代码，其中有一行类似这样的代码

storer = SecretStorePluginManager.getPlugin(
              plugin_managers.STORE_SECRET, meta_data)
storer.store_secret(...)

4. SecretStorePluginManager 将查看配置文件，并查看哪些插件可用。最初它将是 plugin.dogtag、plugin.kmip 或 plugin.store_crypto 中定义的实现之一。

5. 如果插件是 dogtag 或 kmip，则 store_secret() 将直接由插件代码实现。

6. 如果插件是 store_crypto 适配器，则 store_secret() 将反过来调用 common.plugin_manager.py 来查找 crypto/security-module 类型的插件（即二级 stevedore 查找）。最初这将是 plugin/crypto/p11_crypto.py 或 simple_crypto.py，并且将像现在一样调用其 encrypt() 方法。

7. 插件返回，更新 meta_data，创建秘密记录并向用户返回 URL。

备选方案¶

更详细的讨论在此 etherpad 上进行：https://etherpad.openstack.org/p/extension-manager

最初的讨论方法是将接口提升到顶层 Barbican 包。然而，这将使它们与“common”、“api”和“task”包（例如）处于同一级别，这将使插件源代码位置更难定位。因此，将所有插件集中在一个明确的“plugin”包下似乎可以提供与其余源代码的适当划分。在“plugin”包下，结构旨在组织接口、默认和外部模块。

数据模型影响¶

无。

REST API 影响¶

无。

安全影响¶

无。

通知影响¶

无。

其他最终用户影响¶

无。

性能影响¶

无。

其他部署者影响¶

无。

开发人员影响¶

这次更改的第一阶段不会产生影响，因为它只设置了新的文件夹结构。一旦现有插件实现被移到新结构中，待处理的 CR 将受到影响，因为文件结构已经改变。但是，我们应该能够与我们的贡献者协调此更改。

实现¶

负责人¶

主要负责人: john-wood-w
其他贡献者: alee-3 rellerreller

工作项¶

CR #1 - 并行添加新结构到当前结构，不应影响: 当前代码库。
CR #2 - 将现有插件移到新结构，包括更新: api/ 和 tasks/ 模块以引用新位置，然后验证单元测试仍然通过。

依赖项¶

无。

测试¶

当前的单元测试需要更改，以引用修订后的项目结构中项的新位置。

文档影响¶

更新此 wiki 部分及其后的部分：https://github.com/cloudkeep/barbican/wiki/Developer-Guide-for-Contributors#detailed-explanation

参考资料¶