WebSocketProxy 中加密和身份验证的支持

https://blueprints.launchpad.net/nova/+spec/websocket-proxy-to-host-security

目前，虽然 noVNC 和 HTML5 SPICE 客户端可以使用 TLS 加密的 WebSockets 与 Websockify 通信（并使用 Nova 控制台令牌进行身份验证），但加密和身份验证到此为止。在 Websockify 和超visor 的 VNC 和 SPICE 服务器之间既没有加密，也没有身份验证。

该蓝图建议引入一个通用的框架，用于支持 Websockify 与计算节点之间代理安全。

问题描述

目前，Websockify 和超visor 的 SPICE 和 VNC 服务器之间既没有身份验证，也没有加密。如果恶意实体获得 OpenStack 部署的“内部”网络的访问权限，他或她可以

  • “监听”VNC 和 SPICE 流量（缺乏加密）

  • 自由连接到 VM 的 SPICE 和 VNC 服务器（缺乏身份验证）

例如，假设 Alice 启动了一台虚拟机，该虚拟机被放置在“hypervisor-a”上。Carol 可以使用 Wireshark 或类似工具来监视 Alice 对其虚拟机控制台的操作。此外，Carol 可以将她的 VNC 客户端指向“hypervisor-a:5900”，并实际访问虚拟机的控制台。

提议的变更

此蓝图将引入一个通用的框架来执行身份验证和加密的代理。在建立连接时，代理将充当服务器的客户端和客户端的服务器，在各自协议的安全协商阶段为每个协议执行不同的步骤。

然后，代理会将服务器套接字包装在一个尊重标准 python 套接字类的加密层中（就像 python 的 ssl 库一样），并将生成的包装套接字传递给正常的代理代码。

身份验证驱动程序将为 SPICE 以及 VNC 拥有一个类（因为 VNC 必须在 RFB 协议的一部分中执行额外的协商）。部署者可以将 Nova 指向通过配置选项的适当驱动程序和选项。

将包含一个用于 TLS [1]（VNC 的 VeNCrypt，SPICE 的纯 TLS）的基本驱动程序作为示例实现，尽管开发进一步的驱动程序，例如 SASL 驱动程序 [2] 将是有益的。

备选方案

  • 执行端到端安全：这将需要在 HTML5 客户端中支持更高级的加密和身份验证。不幸的是，这需要在浏览器中执行密码学，在更多浏览器开始实现 HTML5 WebCrypto API 之前，这实际上是不可行的。

  • 使用像 stunnel 这样的工具：这存在一些问题。首先，它将我们锁定到特定的身份验证机制——stunnel 对于 TLS 来说很好，但如果我们要使用 SASL，则无法工作。第二个问题是它绕过了正常的 VNC 安全协商，后者在明文中执行初始握手，然后在稍后进行安全协商。期望保持在标准 RFB（VNC）规范的范围内。第三个问题是这将回避身份验证问题——除非您明确设置防火墙以阻止对普通 VNC 端口的远程连接（这需要部署者进行更多设置——我们希望使其易于使用），否则恶意实体仍然可以连接到未经过身份验证的端口。

数据模型影响

无。

REST API 影响

无。

安全影响

实际使用的加密将取决于所使用的驱动程序。确保用于任何已实现驱动程序的库实际上是安全的非常重要。

假设驱动程序是安全的并且实现了身份验证和加密，则部署的安全性将得到加强。

通知影响

无。

其他最终用户影响

无。

性能影响

最小。额外的加密很可能通过基于 C 的 python 库执行，因此开销相对较低。

其他部署者影响

首先，部署者必须选择他或她想要使用的驱动程序：console_proxy_security_driver = driver_name。然后，特定的驱动程序将在配置文件中自己的部分下拥有配置选项。例如，x509/TLS 驱动程序将显示如下

[console_proxy_tls]
ca_certificate = /path/to/ca.cert
client_certificate = /path/to/client.cert

最后，大多数驱动程序都需要 Nova 之外的额外设置。例如，x509/TLS 驱动程序需要生成 CA、客户端和服务器证书，分发 CA 和客户端证书，并配置 libvirt 以在连接到 VNC 和 SPICE 控制台时需要 x509/TLS 加密和身份验证（请参阅 参考文献）。

开发人员影响

无。

实现

负责人

主要负责人

sross-7

其他贡献者

无

工作项

  1. 实现代理身份验证和加密的基本框架。

  2. 实现一个 No-op 驱动程序

  3. 实现基本的 x509/TLS 驱动程序

依赖项

虽然单个驱动程序可能会引入新的依赖项，但实际框架不会。

测试

我们应该测试框架是否可以正确调用。此外，还需要与基础设施团队合作，以确保我们可以测试实际的驱动程序（例如，对于 x509/TLS，我们需要生成证书等）。

文档影响

我们需要记录新的配置选项，以及如何为 TLS 驱动程序生成证书（参见 其他部署者影响）。

参考资料