允许管理员添加 CA¶

https://blueprints.launchpad.net/barbican/+spec/add-cas

问题描述¶

在 Kilo 版本中，添加了代码以允许客户端通过指定 Barbican 定义的 ca_id 来选择后端 CA 服务器。可以通过对 /cas 接口执行 GET 请求来查询这些 ca_id。

此外，现在项目管理员可以将一组 CA 与项目关联，并在未明确请求 CA 的情况下定义首选（或默认）CA。所有这些都意味着项目管理员可以将项目客户端限制为特定的 CA。

现在是时候采取下一步了。Dogtag 已经实现了动态创建后端下级 CA 的能力。我们需要将此功能暴露给项目管理员，以便他们能够创建项目特定的 CA。这将允许向项目中的客户端颁发的所有证书仅限于该项目。

这种项目特定的范围通过隔离客户端来提高安全性，并赋予项目管理员对其证书的更大控制权。本质上，它是一种 PKI 即服务。

提议的变更¶

创建 CA¶

我们已经具备了大部分所需的基础设施。我们需要添加一个 POST /cas 调用来请求创建新的 CA。此调用将限制为项目管理员。此调用至少需要三个参数

用于新 CA 签名证书的主题 DN。
新 CA 的名称或句柄
parent_ca_ref - 要将此 CA 作为下级 CA 的 CA 的引用。也就是说，将颁发新 CA 签名证书的 CA。

可能需要额外的参数来请求下级 CA 签名证书上的特定属性。这些属性当前未在 Dogtag 中公开，因此不会包含在初始实现中。

将在 CertificateManager 接口中添加两种新方法。

supports_create_ca() - 将调用此方法以确定给定的插件是否支持此操作。将添加一个默认实现，返回 False，CertificateManager。支持此选项的插件必须覆盖此函数。
create_ca(ca_create_dto) - 将调用此方法来创建 subCA，将添加一个默认实现，该实现抛出 NotSupported 异常，以便现有插件无需更改。相关参数将通过 ca_create_dto 传递。

Barbican 核心将选择合适的 CA 插件，并调用 create_ca()。如果没有合适的插件，将返回 400 错误。

否则，一旦创建了新的 subCA，该 subCA 的数据将返回给 Barbican 核心，Barbican 核心会将 CA 添加到 CA 表中。

将把新创建的 CA 引用返回给客户端。

CA 所有权¶

将在 CA 表中添加一个额外的“owner”字段。当使用上述机制创建 CA 时，此字段将填充为项目管理员的 project_id。需要进行更改以确保在 Barbican-core 与 CA 插件同步其 CA 表时，此字段不会被覆盖。

通过 /cas 接口创建的（因此由项目拥有的）CA，只能由拥有项目的成员列出和查看。此外，只有该项目的成员才能向该 CA 提交证书订单。

删除 CA¶

只有项目管理员才能删除 CA。要删除 CA，CA 必须由项目拥有。为此，将公开一个新的 REST 方法 DEL /cas/{ca_id}。

此方法将在 CA 表中查找必要的 CA 插件，并调用一个新的 delete_ca(plugin_ca_id) 调用。此调用将在后端 CA 上进行相应的调用，其中包括撤销 CA 签名证书等操作。

成功后，CA 将从 CA 表中删除。

备选方案¶

无。

数据模型影响¶

需要将一个新字段“owner”添加到 CA 表中。

REST API 影响¶

我们需要向 /cas/ 接口添加一些调用。

POST /cas - 创建 CA，如上所述。属性 name、parent_ca_ref 和 subject_dn 是必需的，如下例所示。

POST /v1/cas
Headers:
    X-Project-Id: {project_id}

Content:
{
    "name": "Dogtag CA for Project yxz",
    "parent_ca_ref": "https:///v1/cas/{parent_ca_uuid}",
    "subject_dn": "cn=CA Signing Cert for xyz, dc=example.com"
}

DEL /cas/{ca_id} - 删除 CA 并撤销 CA 签名证书，如上所述。
above。

此外，需要修改 GET /cas 和 GET /cas/{ca_id}（很可能在 DB 查询中），以便“拥有的 CA”只能被项目成员访问。

此外，需要在 Orders 接口中添加一个验证，以确保请求中引用的拥有的 CA 属于请求者的项目。

安全影响¶

无。

通知与审计影响¶

确保根据审计规范审计上述所有操作。[1]

其他最终用户影响¶

python-barbicanclient 需要添加方法来执行新的操作。

性能影响¶

最小。这是一个相对不频繁的管理员操作。

其他部署者影响¶

需要在已经存在的部署上运行迁移脚本，以添加新的“owner”字段。owner 字段将是可为空的，以便代码可以处理有/没有 owner 的情况。

开发人员影响¶

除非插件开发者想要支持新的方法，否则他们不需要进行任何更改。

实现¶

负责人

主要负责人: alee-3

工作项¶

更新 CA 和证书 API 文档。
编写功能测试。
添加新的“owner”字段和迁移脚本。
添加新的 REST API 和内部 Barbican 核心逻辑。
添加 Dogtag 实现。

依赖项¶

无

测试¶

当前的单元和功能测试也将被修改以反映这些更改。

文档影响¶

这是一个需要记录的新功能。

参考资料¶

审计规范 https://review.openstack.org/#/c/159938/。

允许管理员添加 CA