在 Barbican 中使用密钥存储插件

摘要

默认情况下，Barbican 配置为在一个部署中使用一个活动的密钥存储插件。这意味着所有新的密钥都将通过相同的插件机制（即相同的存储后端）存储。

在 Newton OpenStack 版本中，添加了配置多个密钥存储插件后端的功能（规范链接）。作为此更改的一部分，客户端可以选择在其项目级别选择首选的插件后端来存储他们的密钥。

启用多个 Barbican 后端

在特定的部署/用例场景中，可能需要支持多个后端，并且可以通过配置来启用它。

为此，Barbican 部署可以在服务配置中添加多个密钥存储后端。项目管理员可以选择预先选择一个后端作为该项目下创建的密钥的首选选项。在该项目下创建的任何 新 密钥都将使用首选后端来存储其密钥材料。如果没有选择项目级别的存储后端，则新密钥将使用全局密钥存储后端。

可以如下定义多个插件配置。

[secretstore]
# Set to True when multiple plugin backends support is needed
enable_multiple_secret_stores = True
stores_lookup_suffix = software, kmip, pkcs11, dogtag, vault

[secretstore:software]
secret_store_plugin = store_crypto
crypto_plugin = simple_crypto

[secretstore:kmip]
secret_store_plugin = kmip_plugin
global_default = True

[secretstore:dogtag]
secret_store_plugin = dogtag_plugin

[secretstore:pkcs11]
secret_store_plugin = store_crypto
crypto_plugin = p11_crypto

[secretstore:vault]
secret_store_plugin = vault_plugin

当 enable_multiple_secret_stores 启用（为 True）时，属性 stores_lookup_suffix 用于在配置部分中查找支持的插件名称。该部分名称使用模式 ‘secretstore:{one_of_suffix}’ 构建。其中一个插件 必须 显式标识为全局默认值，即 global_default = True。后缀和标签的顺序并不重要，只要在服务配置中定义了匹配的部分即可。

注意

对于现有的 Barbican 部署，建议将现有的密钥存储和加密插件（如果适用）名称组合用作全局默认密钥存储。这需要与现有行为保持一致。

警告

当启用多个插件支持时，enabled_secretstore_plugins 和 enabled_crypto_plugins 值 不 用于实例化相关插件。仅使用上述机制来识别和实例化存储和加密插件。

多个后端在以下类型的用例场景中可能很有用。

  • 在部署中，部署者可能可以接受使用低安全性的密钥存储来存储他们的开发/测试资源，例如使用软件加密的后端，但可能希望对生产资源使用 HSM 支持的密钥存储。

  • 在部署中，对于某些需要对存储密钥进行高并发访问的用例，HSM 可能不是一个好的存储后端。此外，水平扩展它们以提供更高的可扩展性在数据库方面来说是一种代价高昂的方法。

  • HSM 设备通常具有有限的存储容量，因此部署必须主动监控其存储密钥的大小，以保持在限制之下。这在 KMIP 后端比在 PKCS11 后端中更适用，因为插件的存储方法不同。这种方面也可能源于上述用例场景，其中部署将非敏感的（来自开发/测试环境）加密密钥存储在 HSM 中。

  • Barbican 作为 IaaS 服务或平台组件运行，其中某些类别的客户端服务具有严格的合规性要求（例如 FIPS），因此将使用 HSM 支持的插件，而其他服务可能可以接受将密钥存储在仅软件加密插件中。