TLS 和 SSL 简介

在 OpenStack 部署中，有时存在对网络流量的机密性或完整性提出安全要求的场景。通常使用加密措施来实现这一点，例如传输层安全 (TLS) 协议。

在典型的部署中，所有通过公共网络传输的流量都是安全的，但安全最佳实践要求也必须保护内部流量。仅依赖安全域隔离进行保护是不够的。如果攻击者获得对超visor 或主机资源的访问权限，破坏 API 端点，或任何其他服务，他们不应能够轻易地注入或捕获消息、命令，或以其他方式影响云的管理能力。

所有域应使用 TLS 进行保护，包括管理域服务和服务的内部通信。TLS 提供了确保用户与 OpenStack 服务之间的身份验证、不可否认性、机密性和完整性的机制，以及 OpenStack 服务之间的通信。

由于安全套接层 (SSL) 协议中已发布的漏洞，我们强烈建议使用 TLS 代替 SSL，并在所有情况下禁用 SSL，除非需要与过时的浏览器或库兼容。

公钥基础设施 (PKI) 是网络中保护通信的框架。它由一组系统和流程组成，以确保可以安全地发送流量，同时验证各方的身份。此处描述的 PKI 配置文件是互联网工程任务组 (IETF) 公钥基础设施 (PKIX) 配置文件，由 PKIX 工作组开发。PKI 的核心组件是

数字证书

已签名的公钥证书是具有实体可验证数据、其公钥以及其他一些属性的数据结构。这些证书由证书颁发机构 (CA) 颁发。由于证书由受信任的 CA 签名，因此在验证后，与实体关联的公钥保证与所述实体关联。用于定义这些证书的最常见标准是 X.509 标准。当前的 X.509 v3 标准在 RFC5280 中详细描述。CA 颁发证书作为证明在线实体身份的机制。CA 通过从证书创建消息摘要并使用其私钥加密摘要来对证书进行数字签名。

终端实体

用户、进程或系统是证书的主体。终端实体将其证书请求发送到注册机构 (RA) 以供批准。如果获得批准，RA 会将请求转发到证书颁发机构 (CA)。证书颁发机构验证请求，如果信息正确，则生成并签署证书。然后将此签名证书发送到证书存储库。

依赖方

接收经过数字签名的证书的端点，该证书可以通过参考证书上列出的公钥进行验证。依赖方应能够验证证书的整个链条，确保它不存在于 CRL 中，并且还必须能够验证证书上的有效期。

证书颁发机构 (CA)

CA 是终端方和依赖于证书进行认证策略、管理处理和证书颁发的方都信任的实体。

注册机构 (RA)

CA 委托执行某些管理功能的可选系统，包括在 CA 颁发证书之前对终端实体进行身份验证等功能。

证书撤销列表 (CRL)

证书撤销列表 (CRL) 是已撤销的证书序列号的列表。在 PKI 模型中，不应信任提交这些证书的终端实体。撤销可能由于多种原因发生，例如密钥泄露、CA 泄露。

CRL 颁发者

CA 委托发布证书撤销列表的可选系统。

证书存储库

存储和查找终端实体证书和证书撤销列表的位置 - 有时称为证书捆绑包。

PKI 构建了提供加密算法、密码模式和协议以保护数据和进行身份验证的框架。我们强烈建议使用公钥基础设施 (PKI) 保护所有服务，包括对 API 端点使用 TLS。仅凭传输或消息的加密或签名无法解决所有这些问题。主机本身必须是安全的，并实施策略、命名空间和其他控制措施来保护其私有凭据和密钥。但是，密钥管理和保护方面的挑战并不能降低这些控制措施的必要性，或降低它们的重要性。

证书颁发机构

许多组织拥有建立的公钥基础设施和自己的证书颁发机构 (CA)、证书策略和管理，他们应使用这些基础设施为内部 OpenStack 用户或服务颁发证书。在公共安全域面向互联网的组织还需要由广泛认可的公共 CA 签发的证书。对于管理网络的加密通信，建议不要使用公共 CA。相反，我们期望并建议大多数部署部署自己的内部 CA。

建议 OpenStack 云架构师考虑为内部系统和面向客户的服务使用单独的 PKI 部署。这允许云部署者维护对其 PKI 基础设施的控制，并且可以更轻松地请求、签名和部署内部系统的证书。高级配置可以使用用于不同安全域的单独 PKI 部署。这允许部署者维护环境的加密分离，确保一个环境颁发的证书不被另一个环境识别。

用于支持互联网面临的云端点 (或客户界面，其中客户预计只安装标准操作系统提供的证书捆绑包) 上的 TLS 的证书应使用安装在操作系统证书捆绑包中的证书颁发机构进行配置。典型的知名供应商包括 Let’s Encrypt、Verisign 和 Thawte，但还有许多其他供应商。

创建和签名证书涉及管理、策略和技术挑战。这是云架构师或运营商可能希望寻求行业领导者和供应商建议的领域，除了此处推荐的指导之外。

TLS 库

OpenStack 生态系统或 OpenStack 依赖项中的组件、服务和应用程序可以实现或配置为使用 TLS 库。OpenStack 中的 TLS 和 HTTP 服务通常使用 OpenSSL 实现，该 OpenSSL 具有经过 FIPS 140-2 验证的模块。但是，请记住，每个应用程序或服务仍然可能在其使用 OpenSSL 库的方式中引入弱点。

加密算法、密码模式和协议

我们建议使用至少 TLS 1.2。较旧的版本，如 TLS 1.0、1.1 以及所有版本的 SSL（TLS 的前身）容易受到多种公开已知的攻击，因此不得使用。TLS 1.2 可用于广泛的客户端兼容性，但启用此协议时请谨慎。只有在存在强制兼容性要求并且您了解相关风险时，才启用 TLS 版本 1.1。

当您使用 TLS 1.2 并控制客户端和服务器时，密码套件应限制为 ECDHE-ECDSA-AES256-GCM-SHA384。在您不控制两个端点并且使用 TLS 1.1 或 1.2 的情况下，更通用的 HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA 是一个合理的密码选择。

但是，由于本书不打算成为关于密码学的全面参考，我们不希望对您应在 OpenStack 服务中启用或禁用哪些特定的算法或密码模式做出规定。我们想推荐一些权威参考，以获取更多信息

摘要

鉴于 OpenStack 组件的复杂性和部署的可能性数量，您必须注意确保每个组件都获得适当的 TLS 证书、密钥和 CA 配置。后续章节将讨论以下服务

  • 计算 API 端点

  • 身份 API 端点

  • 网络 API 端点

  • 存储 API 端点

  • 消息服务器

  • 数据库服务器

  • 仪表盘