在 tripleo-heat-templates 中移动证书管理¶
Launchpad蓝图
https://blueprints.launchpad.net/tripleo/+spec/ansible-certmonger
问题描述¶
当前使用 Puppet 和 Certmonger 管理证书的方式存在多个问题，尤其是在容器化环境中
多个容器使用相同的证书
在证书更新时，很难确定需要重启哪些容器
共享证书不好
目前的主要问题是 “pkill” 的使用，特别是对于 httpd 服务。由于 Certmonger 不知道哪个容器正在运行 httpd 服务，它会使用一个大范围的“捕蝇纸”，希望所有相关的服务都能有效地使用新的证书重新加载。
在强制 SELinux 主机上，Certmonger 使用 “pkill” 的行为是被阻止的。
提议的变更¶
引言¶
虽然 certmonger 的使用没有问题，但我们使用它的方式有问题。
本文档的目标是描述我们如何改变这种使用方式，从而提供更好的安全性，同时允许 Certmonger 只重启必要的容器，并以一种简单的方式实现。
在 Ansible 中实现 certmonger¶
第一步是在 Ansible 中实现一个 certmonger “模块”。 有两种方法可以做到这一点
可重用角色
原生 Ansible 模块
虽然前者实现起来更快，但后者更好，因为它将允许提供一种干净的方式来管理证书。
将证书管理移动到 tripleo-heat-templates¶
一旦我们有了在 Ansible 中管理 Certmonger 的方法，我们就可以将调用直接移动到相关的 tripleo-heat-templates 文件中，从而生成每个容器的证书。
这样做也将允许 Certmonger 确切地知道在证书更新时重启哪个容器，使用一个简单的 “container_cli kill” 命令。
替代方案¶
提出了一种替代方案
维护一个列表¶
我们可以保持代码不变，并添加一个需要重启/重新加载的容器列表。 Certmonger 将循环遍历该列表，并在证书更新时执行其操作。
这不是一个好的解决方案，因为该列表最终会缺乏更新，这将导致新的问题，而不是解决当前的问题。
此外，它不允许获取每个容器的证书，这是不好的。
建议路线图¶
在 Stein 中
在 tripleo-common 中创建 “tripleo-certmonger” Ansible 可重用角色
在 Train 中
将证书管理/生成移动到 tripleo-heat-templates 中。
评估转向 Certmonger 的适当 Ansible 模块的好处。
如果评估良好并且有时间，则实现它并更新当前代码。
在 “U” 版本中
检查是否有任何内容依赖于 puppet-certmonger，如果不是，则删除此模块。
安全影响¶
我们将通过避免共享 x509 密钥对来提供更好的安全级别。
升级影响¶
每个使用共享证书的容器都将被重启，以便加载新的专用证书。
我们将必须确保 nova 元数据得到正确更新，以便让 novajoin 在 FreeIPA 中创建服务，从而允许请求每个服务的证书。
还应该对 novajoin 更新/升级进行测试，以确保一切正常工作。
如果容器已经在使用专用证书，则预计不会有其他影响。
最终⽤户影响¶
在升级期间，预计会有标准的短时间停机，除非使用 HA 进行部署。
性能影响¶
预计不会有重大的性能影响。
部署者影响¶
预计不会有重大的部署器影响。
开发人员影响¶
添加需要证书的新服务的人需要在新的 tripleo-heat-templates 文件中调用 Certmonger 模块/角色。
他们还需要确保生成新的元数据，以便让 novajoin 在 FreeIPA 中创建相关的服务。
实现¶
贡献者¶
Cédric Jeanneret
Grzegorz Grasza
Nathan Kinder
工作项¶
实现 Certmonger 的可重用角色
将证书管理移动到 tripleo-heat-templates
从 Puppet 中删除 certmonger 部分
更新/创建有关证书管理所需的文档
稍后：* 实现一个适当的 Ansible 模块 * 更新角色以包装模块调用
依赖项¶
无 - 目前，不存在用于 Ansible 的 Certmonger 模块。
测试¶
我们必须确保生成具有正确内容的专用证书，并确保它由正确的容器提供。
我们可以使用 openssl CLI 来实现，也许可以在 tripleo-quickstart-extras 中的新角色中添加一个新的检查。
这与 novajoin 密切相关，因此我们必须确保它按预期工作。
文档影响¶
我们需要记录如何管理证书。
