启用内部通信的 TLS¶
- 日期:
2022-11-16 21:00
- 标签:
ssl, tls, 证书, https, 安全
为了提高 OpenStack-Ansible 部署的安全性，所有流量，包括内部和外部流量都应加密。目前已经支持加密通过 haproxy 后端的所有公共端点的外部流量，但对于所有内部流量而言并非如此。
问题描述¶
这个问题大致可以分为 3 个部分
保护到内部 haproxy VIP 的内部通信
保护从 haproxy 到后端的内部通信
保护诸如 rabbitmq、galera、nova 实时迁移和 noVNC 等服务之间的内部通信
保护到内部 haproxy VIP 的内部通信¶
haproxy 角色中已经存在使用内部 haproxy VIP 上 TLS 的支持，并且已为 AIO 部署启用，但未为新的或现有部署的升级启用。
为新部署启用内部 haproxy VIP 上的 TLS 没有问题，但对于现有部署，需要实施升级流程。需要升级流程的原因是，如果目前在内部 haproxy VIP 上启用 TLS，在每个客户端配置为使用 HTTPS 而不是 HTTP 之前，会导致停机。
需要解决的问题
Haproxy 配置，允许在现有部署中启用 TLS 而不会导致 API 停机
OpenStack-Ansible 升级流程和升级脚本，用于在现有部署中启用 TLS 而不会导致 API 停机
保护从 haproxy 到后端的内部通信¶
保护从 haproxy 到服务后端的通信与保护到内部 haproxy VIP 的通信同样重要。
大量与 haproxy 配合使用的服务使用 UWSGI，这意味着一旦将 TLS 支持添加到 UWSGI 角色，只需配置启用 TLS 和为每个服务生成证书即可。
对于不使用 USWGI 的服务，例如 noVNC Proxy，需要进一步调查。
与为新部署启用内部 haproxy VIP 上的 TLS 一样，为 haproxy 到后端启用 TLS 没有问题，但现有部署需要升级流程。需要升级流程的原因是，如果 haproxy 期望 TLS 后端，但服务尚未启用 TLS，则连接将失败，如果启用服务上的 TLS，连接将失败，因为 haproxy 未配置为 TLS。
需要解决的问题
为 UWSGI 添加 TLS 支持
为每个使用 UWSGI 的服务添加角色配置以启用 TLS
为剩余不使用 USWGI 的服务添加角色配置
在 OpenStack-Ansible 中添加配置以在每个服务的后端启用 TLS
OpenStack-Ansible 升级流程和升级脚本，用于在现有部署中启用后端 TLS 而不会导致 API 停机
保护服务之间的内部通信¶
许多 OpenStack 服务直接相互通信，不使用 haproxy，这些通信也应受到保护。完成这些通信的保护工作已经在 OpenStack-Ansible 的 Yoga 版本中完成并启用，适用于以下服务
RabbitMQ
Galera
Nova 实时迁移
noVNC（noVNC 到计算节点）。
需要解决的问题
保护以下服务
Memcached
etcd
OVN/OVS
是否有任何未包含在列表中且不通过 haproxy 的服务需要保护其通信？
提议的变更¶
启用所有内部通信上的 TLS。
内部通信可以使用自签名证书进行加密，但由于 OpenStack-Ansible 支持使用 ansible-role-pki 从自签名私有证书颁发机构颁发证书，因此应使用它，因为它既加密了数据，又允许客户端信任服务器。
在所有情况下，用户都应能够覆盖由自签名私有证书颁发机构颁发的证书，从而允许他们提供自己的证书，该证书可能由受信任的公共证书颁发机构颁发。
备选方案¶
无，应保护内部通信，TLS 是一种适当且常用的解决方案。
Playbook/Role 影响¶
角色
将添加对使用 ansible-role-pki 角色生成证书的支持到每个服务
将添加配置以启用/禁用 TLS
升级影响¶
可以在升级期间或升级后执行 TLS 启用。
如问题描述部分所述，在现有部署中启用内部 haproxy VIP 和服务后端上的 TLS 会在升级期间导致停机。导致停机的原因是，对于从内部客户端 => 内部 haproxy VIP（服务器）和 haproxy（客户端） => openstack 服务后端（服务器）的通信，客户端和服务器都需要同时更新以使用 TLS。
为了缓解此问题，我建议在升级期间采用中间步骤，其中 haproxy 前端将接受 HTTP 和 HTTPS 通信。这将通过向 haproxy 添加一个新的 TCP 前端来实现，该前端接受 HTTP 和 HTTPS 流量，并重定向到每个前端的正确前端；HTTP 或 HTTPS。这意味着 openstack 客户端可以继续使用相同的知名端口，而 haproxy 会负责将它们重定向到正确的 frontend；HTTP 或 HTTPS。
为了缓解 haproxy<>后端通信问题，我建议实施“分离的 Haproxy 服务配置”功能[1]，该功能在同一个 playbook 中配置 openstack 服务及其 haproxy 服务。
另一个需要注意的问题是，当用户想要使用预定义的证书时，该证书将在所有 VIP 上使用，包括内部和外部 VIP。这意味着，如果在 haproxy 的内部 VIP 上启用了 TLS，则内部客户端必须能够信任呈现的证书（如果它与外部证书相同）。此限制不适用于：- certbot，它可以为外部接口呈现单独的证书。- PKI 角色默认为外部和内部 VIP 安装不同的证书
安全影响¶
此更改将加密所有内部通信，从而保护任何敏感数据，因此安全性得到提高。
性能影响¶
在所有内部通信上实施 TLS 会导致服务器和客户端的处理要求和延迟略有增加，但增加的安全性胜过这些。
最终用户影响¶
无，如果部署正确。
部署者影响¶
部署者需要添加对证书到期日期的监控，并在必要时更新，如果证书过期，服务之间的连接将被中断。
此更改对新部署的部署者没有影响，OpenStack-Ansible 将创建证书、部署它们并将所有服务配置为使用它们。
此更改将影响现有部署，并且将实施升级流程以帮助最大程度地减少甚至防止这种情况。
开发人员影响¶
没有影响，除了流量将被加密，这意味着诸如 tcpdump 之类的工具可能提供的帮助较少，因为它们将无法查看数据包的内容。
依赖项¶
无。
实现¶
负责人¶
- 主要负责人
Damian Dabrowski <damian@dabrowski.cloud>
工作项¶
为 UWSGI 角色启用 TLS 支持
为 haproxy 角色启用 TLS 后端支持
添加配置到使用 UWSGI 的 openstack 服务，以创建 TLS 证书并在 UWSGI 上启用 TLS
添加配置到不使用 USWGI 的剩余 openstack 服务，以启用 TLS 支持
在 OpenStack-Ansible 中添加配置，以允许为服务器和 haproxy 启用所有服务的 TLS
更新 TLS 配置选项的文档
添加升级程序的文档
添加脚本以尽可能自动化升级
测试¶
可以使用现有的设置来测试这些更改，但是需要手动测试升级程序以确保它不会导致任何停机，因为自动化测试仅确认升级结束时正常工作。
文档影响¶
由于此更改将添加额外的配置选项，因此需要记录这些选项。
现有部署的升级程序也需要记录，因为如果未正确部署此功能，可能会导致系统出现故障。
