向订单添加证书生成和管理¶
Launchpad 蓝图: https://blueprints.launchpad.net/barbican/+spec/add-ssl-ca-support
Barbican 可以用于自动化和简化 SSL 证书和相关私钥的生成和存储，这些证书和私钥来自客户端信息（例如 CSR）。此功能需要能够协调多个可能的证书颁发机构 (CA) 进行生成，Barbican 用于安全证书存储，以及在生成完成后进行通知。此蓝图详细介绍了一种基于插件的方法来满足这些要求。
问题描述¶
要在 Barbican 的订单资源中生成和管理 SSL 证书，Barbican 需要执行以下操作：(1) 接受来自客户端的证书信息，(2) 使用多个可能的证书颁发机构 (CA) 中的一个启动证书生成订单，(3) 定期检查每个 CA 订单的进度，(4) 在 CA 生成证书后安全地存储证书信息，最后 (5) 通知客户端证书已准备好进行配置。 此 wiki 页面详细介绍了涉及的流程：https://wiki.openstack.org/wiki/Barbican/Blueprints/ssl-certificates。
Barbican 应该能够与各种不同的 CA 交互，每个 CA 都有其自己的自定义交互流程。 Barbican 应该能够代表此流程在状态之间存储状态（例如，等待 CA 生成证书）。 Barbican 还应该提供一种机制，以便工作流进程可以重新安排回调到工作流进程，例如重试在 CA 中创建证书订单的失败尝试。
Barbican 应该能够通过部署可用的各种事件机制向客户端通知问题或生成的证书。 示例包括通过 Ceilometer 暴露 CADF 事件，或在公司工单系统中发出工单。
Barbican 应该为 CA 工作流进程提供能力，以便无需直接与数据模型交互即可安全地将证书信息存储在 Barbican 中。
Barbican 应该为 CA 工作流进程提供能力，以便在未来某个时间重新安排自身，也许是为了重新尝试与 CA 建立订单等失败的流程。
Barbican 应该允许在启动 CA 订购流程之前验证证书订单字段。 Barbican 应该允许客户端更新有关其启动的 CA 订单的信息，例如提供更正、取消或批准。 此接口还可以支持在证书创建并在 Barbican 中安装后撤销证书。
提议的变更¶
此蓝图建议使用插件方法与特定的 CA 交互。 插件契约将暴露表示工作流操作的处理方法，例如 ‘request_certificate(…)’ 或 ‘check_request_status(…)’。 此蓝图将把这些方法的具体名称和用法委托给实施的 CR。
由于与给定 CA 交互所需的流程/状态处理预计在 CA 供应商之间会有很大差异，因此预计插件需要管理自己的状态机。 但是，CA 插件不必管理为给定订单实例持久化/检索状态机数据。 因此，Barbican 应该处理将信息字典提供到插件的方法中，插件可以在其中引用其状态。 例如，这可能包括一个 ‘state’ 键，用于跟踪订单的状态机状态。 Barbican 然后会将此字典作为插件特定的元数据存储在订单中。
来自工作节点（通过 oslo incubator 的 periodic_task 功能）运行的单独计划进程将轮询 CA 以获取有关待处理证书订单的更新，为每个更新生成 RPC 任务，最终调用上述 CA 插件方法。
还建议使用一个插件来暴露来自 Barbican 的证书事件。 由于 CA 插件在其工作流中知道应该发出事件的最佳时机（例如，当生成证书时），因此建议将事件插件传递到 CA 插件的方法中。 这种控制反转 (IoC) 方法将允许插件控制事件序列，并将与 Barbican 内部和外部事件的处理方式分离。 此插件可以具有针对证书处理工作有意义的领域特定方法，例如 ‘notify_certificate_is_generated()’。 默认的开箱即用插件将只记录事件。 提供的可选事件插件实现将为 Ceilometer 创建 CADF 事件以进行处理。
CA 工作流插件也最了解何时存储生成的证书。 因此，另一个 IoC 适配器将被传递到 CA 插件的方法中，提供诸如 ‘store_certificate()’ 之类的特定方法，该方法将作为 Barbican 容器存储库保存调用来实现。
最后，将传递一个 IoC 适配器到 CA 插件的方法中，允许插件通过排队一个启动 CA 插件的方法的 RPC 调用，在未来的某个时间调用其方法之一。
备选方案¶
上面详细描述的证书生成过程是一个可以使用工作流框架表示的工作流。 下面讨论了其中几个。 它们通常旨在以顺序或并行方式执行一系列预配置的任务，直到完成，如果发生错误，可能会撤消整个序列。
证书处理状态机似乎不适合这种方法，原因有两个
(1) 证书处理涉及 CA 交互状态机步骤之间可能存在很长的延迟（几天），包括轮询 CA 以获取状态更新或等待客户端更新。 延迟和计划轮询行为似乎没有集成到下面现有的工作流方法中，因此 Barbican 需要实现这样的逻辑。
(2) 某些状态步骤可能需要重复，例如在 CA 不可用时重试启动与 CA 的订单。 因此，在这种情况下，执行的任务顺序事先是未知的，并且当发生错误时，完成的任务不应总是被撤消。
期望的是工作流过程能够很好地与 Barbican 工作进程配合使用，包括能够响应来自队列的 RPC 调用，或响应计划的更新请求。
TaskFlow (https://wiki.openstack.org/wiki/TaskFlow) 是一个 OpenStack Python 库，可以使用 Python 类组合任务和工作流。 这些旨在从“引擎”中运行，该引擎管理配置任务的执行。 因此，TaskFlow 最好作为与 Barbican 工作程序分离的单独进程或节点运行。 它似乎最适合此蓝图的需求，但仍然存在上述“适应性”问题。
Mistral (https://wiki.openstack.org/wiki/Mistral) 是一个 OpenStack 工作流即服务项目。 但是，它处于早期阶段，可能在 Juno 或 K 版本中不可用。 它不允许项目上传和执行自定义代码，而是回调 Barbican 以执行其任务。
较低级别的框架，例如 machinist (https://pypi.ac.cn/project/machinist/0.1) 可以作为 Python 对象定义的状态机运行状态机。 像 TaskFlow 一样，这最好作为与 Barbican 工作程序分离的进程运行。 此框架似乎不如 TaskFlow 灵活。
数据模型影响¶
当前的 Orders 实体需要添加一个新的关系来存储 CA 插件的元数据，类似于添加到 Secrets 实体中的键/值元数据存储。 这将与 Orders 的 ‘meta’ 属性不同，后者用于存储用户提供的订购信息。
由于元数据是可选的并且由插件控制，因此不需要数据库迁移。
REST API 影响¶
‘certificate’ 订单类型正在通过另一个更改过程添加，因此此蓝图没有直接的 API 影响。
安全影响¶
Barbican 将与第三方系统（证书颁发机构）交互。 此交互仅由 Barbican 发起，但必须小心验证用户提供的信息（通过证书插件）以及来自 CA 的响应信息。
通知影响¶
此蓝图要求使用插件方法来暴露来自证书生成过程的事件，特别是通知何时生成证书并准备好安装，以及何时发生错误。 错误可能包括 CA 拒绝订单、暂时不可用或限制客户端发出的请求数量。 在某些情况下，Barbican 需要在未来的某个时间重新尝试请求。
此蓝图可能是 Barbican 中事件生成和通知的第一个用例。
其他最终用户影响¶
无。
性能影响¶
上述证书处理的影响应该很小，因为即使批准和生成证书可能需要几天时间，但大部分时间都花在等待 CA 更新给定的证书订单或等待用户提供更正或批准上。 当 Barbican 正在处理状态机步骤时，计算负载应该很小。
此外，预计不会同时处理许多证书订单。 即使负载随着时间的推移而增加，所有证书处理都在工作节点上异步执行，因此将容纳额外的延迟，并且很可能占整体证书工作流周期的很小一部分。
其他部署者影响¶
没有，将使用当前的工作进程。
开发人员影响¶
将向当前的 Barbican 工作程序代码库添加新功能，特别是 oslo incubator 的 periodic_task 实现和事件插件。
实现¶
负责人¶
- 主要负责人
john-wood-w
- 其他贡献者
alee-3 arvind-tiwari
工作项¶
以下 CR 将构建此蓝图
– 添加 CA 插件和验证：1) 添加用于 CA 工作流插件的 stevedore 插件管理器，以及具有工作流处理方法的初始插件抽象接口。 默认实现将只发出日志消息。 从 ‘certificate’ 订单类型的 BeginOrder 任务调用。 添加初始单元测试。
将验证处理添加到 CA 插件。
– 添加事件插件：3) 添加用于事件插件的事件 stevedore 插件管理器，以及具有默认日志记录实现的初始插件抽象接口。
– 添加适配器：4) 添加数据存储适配器并作为 IoC 上下文传递给 CA 插件。 5) 添加任务重试适配器并作为 IoC 上下文传递给 CA 插件。
– 添加订单更新：6) 修改 POST 订单流程以处理验证处理（包括使用上述第 2 步工作）。 7) 向 ‘orders’ 资源添加 PUT 处理程序以处理客户端订单更新。 8) 添加 ‘UpdateOrder’ 任务以异步处理这些更新并相应地调用 CA 插件方法。
– 添加计划进程：9) 将 oslo incubator 的 periodic_task 添加到工作进程。 10) 添加 CA 工作流支持，以定期检查 CA 状态，然后生成更新事件返回到 Barbican 工作程序队列。
– 生产插件实现：11) 添加 CADF/Ceilometer 事件插件实现。 12) 添加 Symantec 插件实现
依赖项¶
与此蓝图相关的插件重构工作应在实施此工作之前完成：https://blueprints.launchpad.net/barbican/+spec/restructure-for-plugins
测试¶
将添加每个插件和适配器的单元测试。 将添加至少默认插件的集成测试。 需要 Symantec 测试，也许使用模拟 Symantec 服务。
文档影响¶
更新 https://github.com/cloudkeep/barbican/wiki/Application-Programming-Interface 以获取 ‘certificate’ 订单类型以及 PUT 到订单的 API 更改。
参考资料¶
与此蓝图相关的正在进行中的 CR 包含草案代码：https://review.openstack.org/#/c/95023/
Symantec CA 工作流的分析在此处提供：https://review.openstack.org/#/c/95023/
与此蓝图相关的插件设计概念，包括 IoC 适配器用法，在此处详细介绍：https://wiki.openstack.org/wiki/Barbican/Discussion-Plugin-Design
