安全参考架构

我们建议在公共网络和管理网络上都使用 SSL/TLS，具体请参阅 TLS 代理和 HTTP 服务。但是，如果实际部署无处不在的 SSL/TLS 过于困难，我们建议评估您的 OpenStack SSL/TLS 需求，并遵循此处讨论的其中一种架构。

评估 OpenStack SSL/TLS 需求时，首先要做的是识别威胁。您可以将这些威胁分为外部攻击者和内部攻击者两类，但界限往往模糊，因为 OpenStack 的某些组件同时在公共网络和管理网络上运行。

对于面向公众的服务，威胁非常直接。用户将使用他们的用户名和密码对 horizon 和 keystone 进行身份验证。用户还将使用他们的 keystone 令牌访问其他服务的 API 端点。如果此网络流量未加密，攻击者可以使用中间人攻击拦截密码和令牌。然后，攻击者可以使用这些有效凭据执行恶意操作。所有实际部署都应使用 SSL/TLS 来保护面向公众的服务。

对于部署在管理网络上的服务，由于网络安全与安全域的桥接，威胁并不那么明显。始终存在管理员访问管理网络并决定执行恶意操作的风险。如果攻击者被允许访问私钥，SSL/TLS 在这种情况下将无法提供帮助。当然，并非管理网络上的每个人都允许访问用于 SSL/TLS 的私钥，因此使用 SSL/TLS 来保护自己免受内部攻击者侵害仍然有价值。即使允许访问您的管理网络的所有人 100% 可信，仍然存在未经授权的用户通过利用错误配置或软件漏洞访问您的内部网络的威胁。必须记住，您在 OpenStack Compute 节点上的实例中运行用户自己的代码，这些节点部署在管理网络上。如果漏洞允许他们突破虚拟机监控程序，他们将可以访问您的管理网络。在管理网络上使用 SSL/TLS 可以最大限度地减少攻击者造成的损害。

SSL/TLS 代理位于前端

普遍认为，尽早加密敏感数据并尽可能晚地解密是最佳做法。尽管如此，似乎通常的做法是在 OpenStack 服务的前面使用 SSL/TLS 代理，然后使用明文通信，如下所示

../_images/secure-arch-ref-1.png

对上述 SSL/TLS 代理使用的一些担忧

  • OpenStack 服务中的原生 SSL/TLS 性能/扩展性不如 SSL 代理（特别是对于 Eventlet 等 Python 实现）。

  • OpenStack 服务中的原生 SSL/TLS 未像更成熟的解决方案那样经过严格审查/审计。

  • 原生 SSL/TLS 配置困难（文档不完善、未经测试或在不同服务之间不一致）。

  • 权限分离（OpenStack 服务进程不应直接访问用于 SSL/TLS 的私钥）。

  • 负载均衡所需的流量检查。

以上所有都是有效的问题，但它们都不会阻止在管理网络上使用 SSL/TLS。让我们考虑下一个部署模型。

SSL/TLS 与 API 端点位于同一物理主机上

../_images/secure-arch-ref-2.png

这与 SSL/TLS 代理位于前端 非常相似，但 SSL/TLS 代理位于与 API 端点相同的物理系统上。API 端点将被配置为仅侦听本地网络接口。所有与 API 端点的远程通信都将通过 SSL/TLS 代理进行。使用此部署模型，我们可以解决 SSL/TLS 代理位于前端 中的许多要点。将使用经过验证且性能良好的 SSL 实现。相同的 SSL 代理软件将用于所有服务，因此 API 端点的 SSL 配置将保持一致。OpenStack 服务进程将没有直接访问用于 SSL/TLS 的私钥，因为您将以不同的用户身份运行 SSL 代理，并使用权限（以及使用 SELinux 等强制访问控制）限制访问。理想情况下，我们希望 API 端点侦听 Unix 套接字，以便我们也可以使用权限和强制访问控制来限制对其访问。不幸的是，根据我们的测试，这目前似乎在 Eventlet 中不起作用。这是一个很好的未来发展目标。

SSL/TLS 通过负载均衡器

对于需要检查流量的高可用性或负载均衡部署，该怎么办？先前的部署模型 (SSL/TLS 与 API 端点位于同一物理主机上) 由于流量已加密，因此不允许进行深度数据包检查。如果流量只需要检查基本的路由目的，则负载均衡器可能不需要访问未加密的流量。HAProxy 能够在握手期间提取 SSL/TLS 会话 ID，然后可以使用它来实现会话亲和性（会话 ID 配置详情在此）。HAProxy 还可以使用 TLS 服务器名称指示 (SNI) 扩展来确定应将流量路由到何处（SNI 配置详情在此）。这些功能可能涵盖了最常见的负载均衡需求。在这种情况下，HAProxy 能够直接将 HTTPS 流量传递到 API 端点系统

../_images/secure-arch-ref-3.png

外部和内部环境的加密分离

如果您希望外部和内部环境的加密分离，该怎么办？公共云提供商可能希望他们的面向公众的服务（或代理）使用由 CA 颁发的证书，该 CA 链接到分发在流行的 Web 浏览器软件中的受信任的根 CA。对于内部服务，人们可能希望使用他们自己的 PKI 来颁发 SSL/TLS 证书。可以通过在网络边界处终止 SSL，然后使用内部颁发的证书重新加密来实现这种加密分离。流量将在公共 SSL/TLS 代理上未加密一段时间，但绝不会以明文形式通过网络传输。用于实现加密分离的相同重新加密方法也可以用于真正需要在负载均衡器上进行深度数据包检查的情况。这是此部署模型的外观

../_images/secure-arch-ref-4.png

与大多数事物一样，存在权衡。主要的权衡将是安全性和性能之间的权衡。加密是有代价的，但被黑客攻击也是有代价的。安全性和性能要求因每个部署而异，因此如何使用 SSL/TLS 最终将是一个单独的决定。