使用 Certmonger 管理超云的 PKI

目前支持为 OpenStack 服务的公共端点启用 SSL。但是，某些用例需要 SSL 存在于所有地方。本规范提出了一种启用它的方法。

问题描述

虽然支持使用 TLS/SSL 支持的公共端点部署超云和下云，但有些部署要求通过所有接口使用加密通信。

当前在 TripleO 中部署 SSL 的方法是通过 Heat 环境变量文件注入所需的密钥/证书；这需要预先创建这些文件。虽然这种方法适用于面向公众的服务，但随着我们尝试保护不同服务之间的通信，以及基础设施的不同层级之间的通信，密钥和证书的数量会增加。因此，让部署者生成所有证书并管理它们将非常繁琐。

另一方面，TripleO 并非旨在处理云的 PKI。而且，考虑到我们最终可能需要启用部署者能够更新、撤销和跟踪云中部署的证书和密钥，我们需要一个具有这些功能的系统。

与其自己构建一个 OpenStack 特定的解决方案，不如我建议使用已经存在的系统，这将使这项工作更容易实现。

提议的变更

概述

建议在超云的节点上开始使用 certmonger[1] 与 CA 交互，以管理正在使用的证书。有了这个工具，我们可以请求获取内部 OpenStack 端点、数据库集群和云消息代理等接口所需的证书。这些证书将反过来进行自动跟踪，并且对于具有识别节点证书的情况，甚至可以在需要时自动请求证书续订。

Certmonger 已经可以在几个发行版（基于 Red Hat 或 Debian）中使用，并且具有与多个 CA 交互的能力，因此如果操作员已经有一个可用的 CA，他们可以使用它。另一方面，certmonger 具有注册新 CA 的机制，并执行脚本（可自定义）以与这些 CA 通信。这些脚本与语言无关。但为了开源社区，可以使用 FreeIPA[2] 或 Dogtag[3] 等解决方案充当 CA 并为我们处理证书和密钥。请注意，如果这是我们想要的方式，可以为 certmonger 编写一个插件来与 Barbican 或另一个 CA 通信。

在 FreeIPA 的情况下，这将需要一个完整的 FreeIPA 系统，运行在集群中的另一个节点上或在下云中的容器中[4]。

对于由 HAProxy 终止的服务，并且超云处于 HA 部署中，控制器节点需要共享一个 HAProxy 在访问时将呈现的证书。在这种情况下，工作流程将如下

1. 将下云注册为 FreeIPA 客户端。这配置了 kerberos 环境并提供了对下云节点的访问控制。

2. 获取与下云对应的 keytab（凭据），以便访问 FreeIPA 并能够注册节点。

3. 创建一个 HAProxy 服务

4. 为该服务创建一个证书/密钥

5. 将密钥存储在 FreeIPA 的 Vault 中。

6. 创建每个要部署的控制器作为 FreeIPA 中的主机（请参阅关于此的说明）

7. 在每个控制器节点上从服务条目中获取证书。

8. 从 FreeIPA vault 中获取密钥。

9. 设置 certmonger 以跟踪生成的证书和密钥。

注意

虽然预先创建每个节点的过程听起来很繁琐，但可以对其进行自动化以提高可用性。建议的方法是在 nova 微服务中自动注册来自超云的节点，并在它们创建时[5]。此钩子不仅会将节点注册到系统中，还会注入一个 OTP，节点可以使用它来获取所需的凭据并获取其相应的证书和密钥。上述 OTP 仅用于注册。注册完成后，就可以使用 certmonger 从 FreeIPA 获取证书了。

但是，即使没有这个微服务，我们也可以通过 TripleO Heat 模板（在超云部署中）传递 OTP。因此，即使我们没有自动注册，也可以让控制器获取其 keytab 并随后请求其证书。

注意

Barbican 也可以代替 FreeIPA 的 Vault 使用。优点是它是一个已经被接受的 OpenStack 服务。但是，Barbican 也需要一个后端，在我们的例子中可能是 Dogtag，因为在 CI 中拥有 HSM 可能不是一个选项。

现在，对于消息代理等需要每个主机一个单独证书的服务，该过程要简单得多，因为节点已经注册到 FreeIPA 中，并且能够获取其凭据。现在我们可以让 certmonger 完成工作并请求，然后跟踪适当的证书。

一旦节点上存在证书和密钥，我们就可以让超云部署过程的后续步骤发生；因此，将配置服务以使用这些证书并启用部署者指定的位置的 TLS。

替代方案

另一种方法是像我们对公共端点所做的那样，直接将证书和密钥注入到节点中。缺点是证书和密钥将被粘贴到 heat 环境变量文件中。对于 RabbitMQ 等服务，我们提供了一个用于通信的节点列表，这将是一个问题，因为要启用 SSL，我们需要为每个充当消息代理的节点提供一个证书。在这种情况下，可以采取两种方法

• 我们需要复制和粘贴每个节点所需的每个证书和密钥。缺点是需要复制多少文本以及难以跟踪证书。另一方面，每当删除或添加节点时，我们需要确保记住在环境变量文件中添加一个证书和一个密钥。因此，这也会成为一个可扩展性和可用性问题。

• 我们也可以提供一个中间证书，并让 TripleO 为每个服务创建证书和密钥。但是，即使这解决了可用性问题，我们仍然无法跟踪云中部署的特定证书和密钥。

安全影响

这种方法可以提高超云的安全性，因为它不仅使我们能够启用所有地方的 TLS（如果需要），还可以帮助我们跟踪和管理 PKI。另一方面，它还可以启用其他安全措施，例如双向身份验证。在 FreeIPA 的情况下，我们可以让节点拥有客户端证书，以便它们能够向服务进行身份验证（就像 HAProxy 或 Galera/MySQL 等工具一样）。但是，这可以作为后续工作。

其他最终用户影响

为此，用户需要将额外的参数传递给超云部署，例如 CA 信息。在 FreeIPA 的情况下，我们需要传递主机和端口、kerberos 领域、下云的 kerberos 主体以及 keytab（凭据）的位置。

但是，这将在文档中反映出来。

性能影响

在所有地方使用 SSL 会降低超云的整体性能，因为每次调用都会有一些开销。然而，这是一个已知问题，这也是为什么所有地方的 SSL 是可选的。它应该只为真正需要它的部署者启用。

使用外部 CA 或 FreeIPA 不应影响超云性能，因为它将执行的操作不是循环操作（颁发、撤销或更新证书）。

其他部署者影响

如果部署者想要启用所有地方的 SSL，他们需要拥有一个可用的 CA 才能使其工作。或者，如果他们没有，他们可以在一个节点上安装 FreeIPA。

开发人员影响

讨论将影响在 OpenStack 上工作的其他开发人员的事情。

实现

负责人

主要负责人

jaosorior

工作项

• 在超云镜像元素中启用 certmonger 和 FreeIPA 客户端工具。

• 在下云安装中包含用于 nova 的主机自动加入钩子。

• 创建将在现有用于 NodeTLSData 和 NodeTLSCAData 的位置使用的嵌套模板。这些模板将执行 certmonger 证书获取和跟踪。

• 配置 OpenStack 内部端点以使用 TLS，并通过 heat 环境变量使其可选。

• 配置 Galera/MySQL 集群以使用 TLS，并通过 heat 环境变量使其可选。

• 配置 RabbitMQ 以使用 TLS（这意味着每个节点都需要一个证书），并通过 heat 环境变量使其可选

• 为所有地方的 SSL 创建一个 CI 网关。这将包括一个 FreeIPA 安装，并为所有服务启用 SSL，最终运行一个 pingtest。对于 FreeIPA 准备，在超云部署之前运行的脚本会将下云添加为客户端，配置其适当的权限并部署一个 keytab，以便它可以利用 nova 钩子。随后，它将为 OpenStack 内部端点和数据库创建一个服务，这将用于创建所需的证书和密钥。

依赖项

• 这需要修复 Nova 中的以下错误：https://bugs.launchpad.net/nova/+bug/1518321

• 还需要打包 nova 钩子。

测试

我们需要创建 CI 中的一个新网关来测试此功能。

文档影响

需要创建关于如何使用外部 CA 以及如何使用 FreeIPA 与 TripleO 的文档。

参考资料

[1] https://fedorahosted.org/certmonger/ [2] http://www.freeipa.org/page/Main_Page [3] http://pki.fedoraproject.org/wiki/PKI_Main_Page [4] http://www.freeipa.org/page/Docker [5] https://github.com/richm/rdo-vm-factory/blob/use-centos/rdo-ipa-nova/novahooks.py