红帽全球峰会安全与强化指南
最佳实践、合规性和安全强化
摘要
第 1 章 简介
安全性对安全性至关重要，对于任何部署而言，安全性应非常注重。数据泄漏和停机时间昂贵且难以管理，法律可能需要通过审计和合规性流程，而项目则可能期望对数据的特定级别隐私和安全性。本节一般介绍了 Red Hat OpenStack Platform 中的安全性，以及红帽支持您系统的安全性的红帽角色。
本文档提供了有关强化 Red Hat OpenStack Platform 部署安全性的建议和良好的实践信息，重点放在基于 director 的部署中。虽然遵循本指南中的说明将有助于增强您的环境的安全性，但我们不保证遵循这些建议的安全性或合规。
1.1. 基本 OpenStack 概念
1.1.1. 什么是 OpenStack？
要了解 OpenStack 是什么，首先需要了解什么是 云。简单的版本是云计算正在为消耗进行处理能力、磁盘存储、数据库处理和网络服务，从而允许客户通过一组 API 与它们交互。
将此方法与专注于托管虚拟机(VM)的传统虚拟机监控程序产品进行比较：虚拟机使用与传统物理独立服务器相同，其中一位系统管理员将调配虚拟机，可能具有不同的系统管理员登录并安装数据库应用程序或其他软件。然后，虚拟机运行数年，在本地（或附加 SAN）上存储数据，并且每天备份。
正确说，OpenStack 也运行虚拟机，但管理方法从上述过程有很大不同。实例应当在创建后可用，并且应用就绪，不需要进一步的配置。如果遇到了问题，您应该部署一个新的替换实例，而不是花费时间对故障进行故障排除。
OpenStack 具有完整的服务选择，它们一起完成上述描述的内容，但这只是许多用例之一。
如需更多信息，请参阅 OpenStack 产品指南 ：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/product_guide/
1.1.2. 关键术语
在继续执行本指南的其余部分之前，建议您熟悉一些新用户早期遇到的 OpenStack 特定术语。
-
实例：这是虚拟机。它们托管在专用的虚拟机监控程序服务器上，称为 Compute 节点。 -
项目：一种 OpenStack 资源的分区集合，组合用户、实例和虚拟网络（其他内容除外）。通过项目，您可以把一个用户和实例的集合与另一个集合分开。这可用于托管多个不同部门或组织的 OpenStack 部署。管理员必须为他们创建的每个用户或实例指定目标项目。 -
图像：操作系统模板。在创建实例时，您需要决定将运行哪些操作系统。OpenStack 允许您选择称为 映像 的操作系统模板。预建的镜像可用于 CentOS 和 Red Hat Enterprise Linux。 -
类别：虚拟机硬件模板。您可以定义一个 类别 来预配置这些值，而不必指定每次构建实例时要分配多少 RAM 和 CPU。您的 Red Hat OpenStack Platform 部署将已定义了类别（从m1.tiny定义，带有 1GB RAM），到使用 16GB 的m1.xlarge。 -
安全组：这些是防火墙规则。每个项目可以有自己的 安全组，定义允许进入或离开网络的流量。
1.1.3. 使用 Director 进行配置管理
Red Hat OpenStack Platform director 允许您使用 YAML 模板部署和管理 OpenStack 环境。这可让您轻松查看如何配置设置。OpenStack 配置文件由 Puppet 管理，因此无论运行 openstack overcloud deploy 进程时，任何非受管更改都会被覆盖。这样，您可以保证您的 YAML 配置在特定时间点实际实际。这种方法还允许您在 OpenStack 部署中具有一种一致、可审计和可重复的方法来进行安全配置管理。对于灾难恢复，director 使用配置管理和编排还可提高恢复时间，因为云部署和配置已进行了编码。
另外，您可以使用部署时通过的自定义环境文件添加自己的自定义自定义。
如需更多信息，请参阅 Director 指南： https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/director_installation_and_usage/
1.2. Security Boundaries 和 Threats
为了了解云部署本身的安全风险，提取提取为具有通用功能、用户和共享安全问题的组件集合会很有帮助。威胁者和向量会按照其动机和对资源的访问进行分类。其目的是让您了解每种区域的安全顾虑，具体取决于您的目标。
1.2.1. 安全区
安全区由用户在系统中共享共同信任要求的用户、应用程序、服务器或网络组成。通常，它们共享相同的身份验证和授权要求和用户。虽然您可能进一步优化了这些区域定义，但本指南引用了以下不同的安全区域，这构成了部署安全强化的 OpenStack 云所需的最小性最小。这些安全区被列为从至少被信任到最受信任：
- public 区域 - 面向公共的 API、neutron 外部网络（用于实例外部连接的浮动 IP 和 SNAT）。
- 客户机区域 - 项目网络(VLAN 或 VXLAN)。
- Storage Access zone - Storage Management （存储监控和集群）、存储(SAN/object/block Storage)。
- 管理区 - Typically 包括 undercloud、主机操作系统、硬件和网络、Undercloud control plane ( overcloud 主机的置备/管理)、overcloud sysadmin/monitoring/backup
- admin zone - 允许通过 overcloud 进行端点访问，包括基础架构 API、DB、RPC （具体取决于 overcloud 上项目的不同 API 访问角色）。overcloud 的管理员访问权限不应要求管理对 undercloud 和硬件的访问权限。
这些安全区可以单独映射，或合并为给定 OpenStack 部署中的大多数可能信任区域。例如，一些部署拓扑可能由一个物理网络上的区组合组成，而其他拓扑则具有独立的区域。对于每个情况，您应该了解适当的安全问题。安全区应映射到特定的 OpenStack 部署拓扑。这些区域及其信任要求将因云实例是公共、私有还是混合而异。
1.2.1.1. 公共区
公共安全区是云基础架构的一个完全不受信任的区域。它可以将互联网称为整个互联网，或者简单地指您没有授权的红帽 OpenStack Platform 部署外部的网络。遍历此区域的机密性或完整性要求的任何数据都应使用补偿控制进行保护。
始终认为此区域不被信任。
1.2.1.2. 客户机区域
通常用于计算实例到实例流量，客户机安全区域负责处理云中实例生成的计算数据，但不处理支持云操作的服务，如 API 调用。
在实例上没有字符串控制的公共和私有云供应商，或者允许不受限制的互联网访问实例访问实例应该认为此区域不被信任。只有实施了正确的控件以表示实例及所有相关项目（包括底层硬件和内部网络）时，私有云供应商可能希望将此网络视为内部且可信。
1.2.1.3. 存储访问区
在此网络中传输的大部分数据都需要高级别的完整性和保密性。在某些情况下，根据部署的类型，也可能具有强大的可用性要求。
除非绝对必要，否则不应在部署外访问存储访问网络。在例外复制要求的情况下，假定此网络被假定无法从云外部访问，除存储设备之外，部署到此区域的组件应当被视为来自安全视角的敏感性。
此网络的信任级别很大程度上依赖于部署决策，因此本指南不会为该区域分配默认信任级别。
1.2.1.4. Control Plane
control plane 是服务交互的位置。此区域传输机密数据的网络，如配置参数、用户名和密码。命令和控制流量通常位于此区域中，需要强大的完整性要求。对此区域的访问应高度限制和监控。同时，此区域应该仍然采用本指南中描述的所有安全良好做法。
在大多数部署中，此区域被视为可信。但是，在考虑 OpenStack 部署时，有许多系统与其它区域桥接，可能会降低您可以在该区域上的信任级别。
1.2.1.5. 管理网络
管理网络用于系统管理、监控和/或备份，但是在没有托管 OpenStack API 或控制接口的地方。此位置是您放置用于内部和/或私有 Red Hat OpenStack Platform 部署的 PXE 网络，包括适用于 director 和 compute/storage/management 节点的任何硬件管理接口、网络设备和底层操作系统访问。
1.3. 连接安全区
必须仔细配置跨多个安全区（具有不同信任级别或身份验证要求）的组件。这些连接通常是网络架构的弱点，并且应始终配置为满足所连接任何区域的最高信任级别。在很多情况下，安全控制所连接的区域应该是一个主要关注，因为攻击的可能性。区域满足点会产生额外的攻击服务，并为攻击者添加对部署更敏感部分的攻击机会。
在某些情况下，OpenStack 操作员可能需要考虑保护集成点比它所在的任何区域更高的标准。根据上述 API 端点示例，一个 adversary 可能会将公共 API 端点从 public 区域为目标，利用此 foot 代表在管理区中破坏或获取对管理区内内部或管理 API 的访问权限（如果这些区没有被完全隔离）。
OpenStack 的设计是很难分离安全区。由于核心服务通常至少跨越两个区域，因此在将安全控制应用到它们时，必须考虑特殊考虑。
1.4. 威胁分类、执行器和攻击向量
大多数类型的云部署、公共、私有或混合云都暴露于某种形式的攻击。本节对攻击者进行分类，并总结每个安全区中潜在的攻击类型。
1.4.1. 威胁行为
威胁者是一个抽象的、用于指代您可能需要防御的一类行为的方式。能够使用更加强大的安全控制，这是成功攻击缓解和防止所需的安全控制。安全性是根据要求进行的平衡便利、防御和成本方面的问题。在某些情况下，无法针对此处所述的所有威胁参与者保护云部署。在部署 OpenStack 云时，您必须决定部署和使用的平衡情况。
作为风险评估的一部分，您还必须考虑您存储和任何可访问资源的数据类型，因为这将影响某些参与者。但是，即使您的数据对威胁者没有吸引人，他们甚至可以只吸引您计算资源，例如参与 botnet 或运行未经授权的加密准确减法。
- nation-State Actors - 这是最强大的 adversary。Nation-state actors 可以使用巨大的资源来进行攻击。他们拥有超越其他任何参与者的功能。在没有严格控制（包括人工和技术）的情况下，很能防御此类的攻击。
- 严重组织 Crime - 该课程描述了高度强大的、经济的攻击者组。他们能够为攻击方法的开发和研究提供大量资金。近年来，一些兴起的组织（例如 Russian Business Network，它是一个大型网络犯罪组织），已证明网络攻击如何成为一种商品。工业间谍通常属于这类严重犯罪组织。
- 高度可疑的组 - 这是指通常不是商业资金的"Hacktivist"类型组织，但可能会对服务提供商和云操作员造成严重威胁。
- 单独激励个人法案 - 这些攻击者在恶意或恶意员工（如恶意或恶意员工）中出现，不影响客户或小型行业高峰。
- 脚本 Kiddies - 这些攻击者不会针对特定组织为目标，但运行自动漏洞扫描和利用。它们通常看似微不足道，但可能会对一个机构构成声誉风险。
以下实践可帮助缓解上述发现的一些风险：
- 安全更新 - 您必须考虑底层物理基础架构（包括网络、存储和服务器硬件）的端到端安全状况。这些系统需要自己的安全强化实践。对于 Red Hat OpenStack Platform 部署，您应该有一个计划定期测试和部署安全更新。
- 访问管理 - 当向个人授予系统访问权限时，您应该应用 最小特权的原则，并且仅向他们授予他们实际需要的粒度系统特权。您可以使用 AAA （访问、授权和会计）来实施此策略。这种方法还可以帮助缓解系统管理员中恶意执行者和排字错误的风险。
- 管理内部 - 您可以通过应用谨慎地分配基于角色的访问控制（主要要求访问），并使用身份验证/授权安全（如集中式身份管理）来缓解恶意内部的威胁。您还可以考虑额外的非技术选项，例如将职责分离和不定期的作业角色轮转。
1.4.1.1. 出站攻击和风险
应谨慎考虑云部署潜在的出站滥用。云部署往往具有大量可用的资源；通过黑客制或有授权访问权限的攻击者，无论是黑客或有权利的访问权限（如恶意员工）可以使用这些资源作为恶意目的。具有计算服务的云使得 DDoS 和 brute 强制引擎成为理想选择。这个问题对于公共云来说尤其如此不可靠，而且可以快速启动大量实例以进行出站攻击。防止方法包括出口安全组、流量检查、入侵检测系统、客户教育和认知以及欺诈以及滥用的缓解策略。对于可通过 或 访问公共网络（如互联网、流程和基础架构）访问的部署，最好地检测并解决出站滥用。
1.5. 支持软件
支持整个红帽解决方案堆栈是安全的软件供应链。红帽安全战略的基石是，这种战略性重要的实践和流程旨在交付具有安全内置前期和支持的解决方案。红帽采取的具体步骤包括：
- 保持上游关系和社区参与，以帮助从一开始专注于安全性。
- 根据安全和性能跟踪记录选择和配置软件包。
- 从相关源代码构建二进制文件（而不是只接受上游构建）。
- 应用一系列检查和质量保证工具，以防止大量潜在安全问题和回归问题。
- 数字签名所有已发布的软件包，并通过经过加密验证的分发频道进行发布。
- 提供单一统一的补丁和更新分发机制。受 OpenStack 的红帽企业 Linux 和 KVM 组件还通过了通用标准认证。这涉及执行物理站点访问的第三方审核员，以及关于遵守良好做法的采访人员，例如，供应链或开发。
此外，红帽还维护了一个专门的安全团队，针对我们的产品分析威胁和漏洞，并通过客户门户网站提供相关建议和更新。这个团队决定哪些问题很重要，而不是与大多数理论问题相关的问题。红帽产品安全团队在维护了专业技术方面，并对与订阅产品关联的上游社区做出了大量贡献。红帽安全公告 （红帽安全公告）的一个主要部分提供了影响红帽解决方案的安全缺陷通知 - 通常会在漏洞首次发布之日提供相关的补丁程序。
1.6. 系统文档
1.6.1. 系统角色和类型
通常构成 OpenStack 安装的两个广泛定义节点类型有：
- 基础架构节点 - 这些运行与云相关的服务，如 OpenStack API 供应商（如 neutron）、消息排队服务、存储管理、监控、网络，以及支持云操作和调配所需的其他服务。
- 计算、存储或其他资源节点 - 为云上运行的实例提供计算和存储容量。
1.6.2. 系统清单
文档应当提供 OpenStack 环境的一般说明，并涵盖使用的所有系统（如生产、开发或测试）。记录系统组件、网络、服务和软件通常会提供彻底覆盖和考虑安全问题、攻击向量和可能的安全区桥接点所需的视角。系统清单可能需要捕获临时资源，如虚拟机或虚拟磁盘卷，而这些资源可能只是传统 IT 环境中的持久资源。
1.6.3. 硬件清单
没有对编写文档的严格合规要求的云可能受益于具有配置管理数据库(CMDB)。CMDB 通常用于硬件资产跟踪和整个生命周期管理。通过利用 CMDB，组织可以快速识别云基础架构硬件，如计算节点、存储节点或网络设备。CMDB 可以协助识别网络上可能存在安全漏洞的资产，因为维护、不精确保护或被移除和禁止。如果底层硬件支持所需的自动发现功能，OpenStack 调配系统可以提供一些基本的 CMDB 功能。
1.6.4. 软件清单
与硬件一样，OpenStack 部署中的所有软件组件都应进行记录。示例包括：
- 系统数据库，如 MySQL 或 mongoDB
- OpenStack 软件组件，如身份或计算
- 支持组件（如负载均衡器、反向代理、DNS 或 DHCP 服务）在评估库、应用程序或软件类的破坏或漏洞影响时，对软件组件的权威列表可能至关重要。
1.6.5. 网络拓扑
网络拓扑应当提供特别调用安全区域之间的数据流和桥接点的亮点。网络入口和出口点应和任何 OpenStack 逻辑系统边界一起识别。可能需要多个图表以提供全面的系统可视化信息。网络拓扑文档应包括由系统代表项目创建的虚拟网络，以及 OpenStack 创建的虚拟机实例和网关，以及用于提供节点和外部网络之间的通信的物理和覆盖网络。
1.6.6. 服务、协议和端口
了解机构资产的信息通常是一个很好的做法。资产表可以帮助验证安全要求，并帮助维护标准安全组件，如防火墙配置、服务端口冲突、安全补救区域和合规性。此外，该表格还可帮助确定 OpenStack 组件之间的关系。表可能包括：
- 在 OpenStack 部署中使用的服务、协议和端口。
- 所有在云基础架构中运行的服务的概述。
建议 OpenStack 部署保留此信息的记录。有关 director 部署所需的端口列表，请参阅 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/firewall_rules_for_red_hat_openstack_platform/。
端口配置也包含在每个服务的 heat 模板中。您可以使用以下命令提取这些信息：
find -L /usr/share/openstack-tripleo-heat-templates/ -type f | while read f;do if `grep -q firewall_rules $f`;then echo -e "\n $f " ; grep firewall_rules "$f" -A10;fi; done
第 2 章 加密和密钥管理
在设备间通信是严重的安全问题。通过网络进行安全通讯的方法变得越来越重要，如大量漏洞（如 Heartbleed）或更高级的攻击，如 BEAST 和 CRIME 等。但是，加密只是一个更大的安全策略的一部分。端点的破坏意味着攻击者不再需要破坏使用加密，但能够查看和操作消息。
本章将回顾关于将传输层安全(TLS)配置为保护内部和外部资源的功能，并将称为应该特别关注的特定系统类别。
OpenStack 组件使用各种协议相互通信，通信可能涉及敏感或机密数据。攻击者可能会试图窃听频道，以获取对敏感信息的访问。因此，所有组件都必须使用安全通信协议相互通信。
2.1. TLS 和 SSL 简介
在某些情况下，需要确保 OpenStack 部署中网络流量的保密性或完整性。您通常使用加密措施（如 TLS 协议）进行配置。在典型的部署中，通过公共网络传输的所有流量都应强化，但安全良好的实践要求内部流量也必须受到保护。它不足而无法依赖安全区分离来保护。如果攻击者可以获得虚拟机监控程序或主机资源的访问权限，请危害 API 端点或任何其他服务，他们必须能够轻松地注入或捕获消息、命令或以其他方式影响云的管理功能。
您应该安全强化使用 TLS 的所有区域，包括管理区域服务和内部服务通信。TLS 提供了相应的机制，可确保身份验证、非对 OpenStack 服务的用户通信以及 OpenStack 服务本身之间的保密性、保密性和完整性。
由于安全套接字层(SSL)协议中发布的漏洞，请考虑使用 TLS 1.2 或更高版本到 SSL，且所有情况下都禁用了 SSL，除非您需要与过时的浏览器或库兼容。
2.1.1. 公钥基础架构
公钥基础架构(PKI)是一种框架，用于提供加密算法、密码模式以及用于保护数据和身份验证的协议。它由一组系统和流程组成，以确保在验证方身份时可以加密流量。此处描述的 PKI 配置集是 PKIX 工作组开发的互联网工程任务 Force (IETF)公钥基础架构(PKIX)配置集。PKI 的核心组件有：
- 数字证书 - 签名的公钥证书是具有可验证实体数据的数据结构、其公钥以及一些其他属性。这些证书由证书颁发机构(CA)发布。当证书由受信任的 CA 签名时，验证后，与该实体关联的公钥可以保证与 said实体相关联。定义这些证书的最常见标准是 X.509 标准。RFC5280 中详细描述了当前标准的 X.509 v3，并由 RFC6818 更新。证书由 CA 发布，作为证明在线实体身份的机制。CA 通过从证书创建消息摘要并使用其私钥加密摘要来对证书进行数字签名。
- 结束实体 - 证书主体的用户、进程或系统。最终实体将证书请求发送到注册机构(RA)以供审批。若获得批准，RA 将请求转发到认证认证机构(CA)。认证认证机构验证请求以及信息是否正确，是否生成并签署证书。然后，这个签名证书会被发送到证书存储库。
- 依赖方 - 接收数字签名证书的端点，该端点可通过引用证书中列出的公钥进行验证。依靠方验证该链的证书，确保 CRL 不存在，并且必须能够验证证书过期日期。
- 证书颁发机构(CA)- CA 是一个可信实体，由终端方和依赖认证策略的方、管理处理和证书保护。
- 注册机构(RA)- CA 委派特定管理功能的可选系统，其中包括的功能，例如：在由 CA 发布证书前验证最终实体的功能。
- certificate Revocation Lists (CRL)- A Certificate Revocation List (CRL)是已撤销的证书序列号列表。显示这些证书的最终实体不应在 PKI 模型中信任。撤销可能会因为几个原因（如密钥泄露）和 CA 危害而发生。
- CRL issuer - CA 将发布证书撤销列表的可选系统。
- 证书存储库 - 最终实体证书和证书撤销列表的位置被存储并查询 - 有时被称为证书捆绑包。
强烈建议您使用公共密钥基础架构(PKI)安全强化所有服务，包括将 TLS 用于 API 端点。无法加密或单独签名传输或消息来解决所有这些问题。另外，还必须对主机本身进行强化和实施策略、命名空间和其他控件来保护其私有凭证和密钥。然而，关键管理和保护的挑战并不能降低这些控制的必要性，或者降低它们的重要性。
2.1.2. 认证授权
许多组织有自己认证认证机构(CA)、证书策略和用于为内部 OpenStack 用户或服务签发证书的证书管理，许多组织已建立了建立了公共密钥基础架构。公共安全区面临的公共安全区的组织还需要由广泛认可的公共 CA 签名的证书。对于通过管理网络的加密通信，建议不要使用公共 CA。相反，建议大多数部署部署自己的内部 CA。
TLS 的有效使用取决于 DNS 中给定域或子域，这些域可以由通配符使用，或者由公共或内部 CA 使用的一系列特定证书问题。为确保可以有效地验证 TLS 证书，需要通过这些 DNS 记录访问平台服务。
建议 OpenStack 云架构考虑将单独的 PKI 部署用于内部系统和面向服务的客户。这使得云部署器可以保持对 PKI 基础架构的控制，并使请求、签名和部署证书更易于内部系统。高级配置可能会对不同的安全区使用单独的 PKI 部署。这使得 OpenStack 操作员能够维护环境的加密分离，确保颁发的证书被另一个软件识别。
用于在面向互联网的云端点（或客户不应该安装标准操作系统提供证书捆绑包以外的任何接口）上支持 TLS 的证书应使用在操作系统证书捆绑包中安装的证书颁发机构来置备。
有关创建和签名证书方面的管理、策略和技术挑战。这是一个领域，云架构师或操作员可能希望在这里所推荐的指南之外寻求行业领袖和供应商的建议。
2.1.3. 使用 Director 配置加密
默认情况下，overcloud 将未加密的端点用于其服务。这意味着 overcloud 配置需要额外的环境文件来为其公共 API 端点启用 SSL/TLS。高级 Overcloud 自定义 指南描述了如何配置 SSL/TLS 证书并将其作为 overcloud 创建流程的一部分包括 ：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud
2.1.4. TLS 库
可以将 OpenStack 生态系统中的某些组件、服务和应用程序配置为使用 TLS 库。OpenStack 中的 TLS 和 HTTP 服务通常使用 OpenSSL 实施，该模块经过 FIPS 140-2 验证的模块。但请考虑每个应用程序或服务在它们如何使用 OpenSSL 库时仍可能会带来弱点。
2.1.5. TLS 1.0 弃用
需要 FedRAMP-authorized 系统才能从 TLS 1.0 移出。推荐的级别是 1.2，只有在需要广泛兼容性时才接受 1.1。如需更多信息，请参阅 https://www.fedramp.gov/assets/resources/documents/CSP_TLS_Requirements.pdf。
对于 Red Hat OpenStack Platform 13 部署，HAProxy 不会接受 TLS 1.0 连接，该连接处理启用了 TLS 的 API 的 TLS 连接。这通过 no-tlsv10 选项实现。对于启用了 InternalTLS 的 HA 部署，controller plane 上的跨节点流量也会加密。这包括 RabbitMQ、MariaDB 和 Redis 等。MariaDB 和 Redis 已被弃用 TLS1.0，RabbitMQ 的弃用应该可从上游向后移植。
2.1.5.1. 检查 TLS 1.0 是否在使用中
您可以使用密码 来确定部署是否显示 TLS 1.0。可从 https://github.com/mozilla/cipherscan 克隆 Cipherscan。本例输出演示了从 horizon 接收的结果：
从非生产系统运行 密码，因为它可能会在第一次运行时安装其他依赖项。
$ ./cipherscan https://openstack.lab.local .............................. Target: openstack.lab.local:443 prio ciphersuite protocols pfs curves 1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 2 ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 3 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,1024bits None 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,1024bits None 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-256,256bits prime256v1 6 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-256,256bits prime256v1 7 ECDHE-RSA-AES128-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 8 ECDHE-RSA-AES256-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,1024bits None 10 DHE-RSA-AES128-SHA TLSv1.2 DH,1024bits None 11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,1024bits None 12 DHE-RSA-AES256-SHA TLSv1.2 DH,1024bits None 13 ECDHE-RSA-DES-CBC3-SHA TLSv1.2 ECDH,P-256,256bits prime256v1 14 EDH-RSA-DES-CBC3-SHA TLSv1.2 DH,1024bits None 15 AES128-GCM-SHA256 TLSv1.2 None None 16 AES256-GCM-SHA384 TLSv1.2 None None 17 AES128-SHA256 TLSv1.2 None None 18 AES256-SHA256 TLSv1.2 None None 19 AES128-SHA TLSv1.2 None None 20 AES256-SHA TLSv1.2 None None 21 DES-CBC3-SHA TLSv1.2 None None Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature TLS ticket lifetime hint: None NPN protocols: None OCSP stapling: not supported Cipher ordering: server Curves ordering: server - fallback: no Server supports secure renegotiation Server supported compression methods: NONE TLS Tolerance: yes Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
扫描服务器时，Cipherscan 会公告特定 TLS 版本的支持，这是它要协商的最高 TLS 版本。如果目标服务器正确遵循 TLS 协议，它将使用相互支持的最高版本进行响应，这可能低于最初公告的 Cipherscan。如果服务器继续使用该特定版本与客户端建立连接，则它不会考虑那个协议版本。如果没有建立连接（在指定版本或任何较低版本的情况下），则被视为存在该版本的协议。例如：
Intolerance to: SSL 3.254 : absent TLS 1.0 : PRESENT TLS 1.1 : PRESENT TLS 1.2 : absent TLS 1.3 : absent TLS 1.4 : absent
在此输出中，TLS 1.0 和 TLS 1.1 会被报告为 PRESENT，这意味着无法建立连接，Cipherscan 无法在这些 TLS 版本的广告支持的同时连接。因此，合理地得出结论，在扫描的服务器上不会启用这些协议（及任何较低）版本。
2.1.6. 加密算法、加密模式和协议
您应该只使用 TLS 1.2。其他版本（如 TLS 1.0 和 1.1）会受到多种攻击，并被许多政府机构和监管行业所禁止。TLS 1.0 应该在您的环境中被禁用。TLS 1.1 可以用于广泛的客户端兼容性，但在启用此协议时要谨慎。只有存在强制兼容性要求并且了解相关风险时，才启用 TLS 版本 1.1。由于多个公共漏洞，不能使用所有版本的 SSL ( TLS 的前身)。
当您使用 TLS 1.2 并控制客户端和服务器时，密码套件应限制为 ECDHE-ECDSA-AES256-GCM-SHA384。如果您无法控制端点，并且正在使用 TLS 1.1 或 1.2 更为常规的 HIGH:!aNULL:!eNULL:!DES:!3DES:!SSLv3:!TLSv1:!CAMELLIA 是合理的密码选择。
本指南不是作为加密文档的参考，在 OpenStack 服务中应该启用或禁用特定算法或密码模式。
2.2. TLS Proxies 和 HTTP 服务
OpenStack 端点是 HTTP 服务，为公共网络上的最终用户提供 API，以及管理网络上的其他 OpenStack 服务。目前，您可以使用 TLS 加密外部请求。要在 Red Hat OpenStack Platform 中配置此功能，您可以在 HAproxy 后部署 API 服务，该服务能够建立和终止 TLS 会话。
如果软件终止提供性能不足，则可能需要探索硬件加速器作为替代选项。此方法需要在平台上进行额外的配置，而并非所有硬件负载均衡器都可能与红帽 OpenStack 平台兼容。请记住，任何选择的 TLS 代理将处理的请求大小非常重要。
2.2.1. 完美转发 Secrecy
为完美的转发保密配置 TLS 服务器需要仔细规划关键大小、会话 ID 和会话问题单。另外，对于多服务器部署，共享状态也是一个重要的考虑因素。现实部署可能会考虑启用此功能以提高性能。这可以以安全强化的方式完成，但需要对主要管理进行特殊考虑。这些配置超出了本指南的范围。
2.3. 使用 Barbican 管理 secret
OpenStack Key Manager (barbican)是 Red Hat OpenStack Platform 的 secret Manager。您可以使用 barbican API 和命令行集中管理 OpenStack 服务使用的证书、密钥和密码。Barbican 目前支持以下用例：
- 对称加密密钥 - 用于 Block Storage (cinder)卷加密、临时磁盘加密和 Object Storage (swift)对象加密。
- 非对称的密钥和证书 - glance 镜像签名和验证，Octavia TLS 负载均衡。
在本发行版本中，barbican 提供与 cinder、swift、Octavia 和 Compute (nova)组件集成。例如，您可以将 barbican 用于以下用例：
- 支持加密卷 - 您可以使用 barbican 来管理您的 Cinder 加密密钥。此配置使用 LUKS 加密附加到您的实例的磁盘，包括引导磁盘。主要管理方面对用户而言是透明的。
- Glance 镜像签名 - 您可以配置镜像服务(glance)，以验证已上传的镜像没有被篡改。镜像首先使用存储在 barbican 中的密钥进行签名，然后镜像在各自使用前进行验证。
如需更多信息，请参阅 Barbican 指南： https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/manage_secrets_with_openstack_key_manager/
第 3 章 身份和访问权限管理
3.1. 身份
本节包含有关身份的概念信息。
3.1.1. 身份验证
身份验证是任何现实 OpenStack 部署的一个完整部分。谨慎考虑系统设计方面。本主题的完整处理方式已超出本指南的讨论范围，但以下部分将介绍一些关键主题。
在其最基本的情况下，身份验证是确认身份（用户实际上就是他们声称的身份）的过程。熟悉的示例是在登录系统时提供用户名和密码。
OpenStack 身份服务(keystone)支持多种身份验证方法，包括用户名、密码、LDAP 以及其他外部身份验证方法。身份验证成功后，身份服务会为用户提供用于后续服务请求的身份验证令牌。
传输层安全性(TLS)使用 X.509 证书在服务和人员之间提供身份验证。虽然 TLS 的默认模式仅用于服务器端身份验证，但您应该考虑将证书用于客户端身份验证，因为它在美国政府标准中规定。
3.1.1.1. 无效的登录尝试
身份服务(keystone)不提供在重复登录尝试失败后限制帐户访问的方法。重复失败的登录尝试模式通常是暴力攻击的指示。这种攻击在公共云部署中更加广泛。您可以使用外部身份验证系统来缓解这个问题，该系统在配置了失败次数的登录尝试后阻断帐户。然后，可能只解锁帐户以进一步管理干预。
检测技术也可以用于降低损坏。检测涉及频繁的访问控制日志，以识别未经授权访问帐户的尝试。可能的补救包括检查用户密码的强度，或者通过防火墙规则阻止攻击的网络源。您可以在 keystone 服务器上添加限制连接数量的防火墙规则，这有助于降低攻击效率。
另外，检查帐户活动异常登录时间和可疑操作会很有用，并采取纠正措施，如禁用帐户。
3.1.1.2. 多因素身份验证
对特权用户帐户使用多因素身份验证。身份服务可以与提供此功能的外部身份验证服务集成。例如，keystone 可以和 Active Directory、Red Hat Identity Manager、FreeIPA 或通用 LDAP 服务器集成，其中之一可实施多因素身份验证。
本建议有助于缓解可能危害密码攻击的各种暴力强制、社交工程，以及预置攻击。有关与红帽身份管理集成的部署，请参阅 配置和管理身份管理 指南。
3.2. 授权
身份服务支持组和角色概念。在组拥有角色列表时，用户从属于组。OpenStack 服务引用试图访问该服务的用户的角色。OpenStack 策略强制中间件考虑与各个资源关联的策略规则，然后用户的组/角色与关联来确定是否允许访问所请求的资源。
3.2.1. 建立表单访问控制策略
在配置角色、组和用户之前，您应该记录 OpenStack 安装所需的访问控制策略。该政策应当与组织的任何监管或法律要求一致。对访问控制配置的未来修改应遵循正式政策一致。策略应包含用于创建、删除、禁用和启用帐户的条件和流程，以及为帐户分配特权。定期检查策略并确保配置符合批准的策略。
3.2.2. 服务授权
云管理员必须使用每个服务的 admin 角色定义用户。此服务帐户为服务提供授权来验证用户。
计算和对象存储服务可以配置为使用身份服务来存储身份验证信息。身份服务支持 TLS 的客户端身份验证，可能被启用。TLS 客户端身份验证提供了额外的身份验证因素，除了提供用户识别时提供更大的可靠性。当用户名和密码被破坏时，它会降低未经授权的访问的风险。但是，对于每个部署中都可能无法提供证书，还有额外的管理开销和成本。
云管理员应保护敏感的配置文件不受未授权修改的影响。这可以通过使用强制访问控制框架（如 SELinux）进行配置，包括 /var/lib/config-data/puppet-generated/keystone/etc/keystone.conf 文件和 X.509 证书。
使用 TLS 的客户端身份验证需要向服务发布证书。这些证书可由外部或内部证书颁发机构签名。OpenStack 服务默认根据可信 CA 检查证书签名请求的有效性，如果签名无效或者 CA 不可信，则连接将失败。云部署器可能会使用自签名证书 ; 在这种情况下，有效检查必须被禁用，或者证书应标记为可信。要禁用自签名证书验证，在 /etc/nova/api.paste.ini 文件的 [filter:authtoken] 部分中设置 insecure=False。此设置还禁用其他组件的证书。请注意，具体文件路径可能因容器化服务而异。
3.2.3. 管理用户帐户
管理用户帐户应使用 keystone 和支持双因素身份验证的服务（如证书）进行身份验证。外部身份验证服务可包括红帽身份管理或 Microsoft Active Directory。https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/integrate_with_identity_service/ 中描述了与这些服务的集成。这种方法有助于降低可能受到破坏的密码的风险。本建议在使用多因素验证对特权帐户的指南中与 NIST 800-53 IA-2 (1)指南一致。
3.2.4. 最终用户
身份服务可以直接提供最终用户身份验证，或者可以配置为使用外部身份验证方法，以符合组织的安全策略和要求。
3.3. 策略（policy）
每个 OpenStack 服务都包含由访问策略管理的资源。例如，资源可能包含以下功能：
- 创建和启动实例的权限
- 将卷附加到实例的功能
作为 Red Hat OpenStack Platform (RHOSP)管理员，您可能需要创建自定义策略来引入具有不同访问级别的新角色，或者更改现有角色的默认行为。您还需要在更改后验证 API 访问策略，并在无法正常工作时调试这些策略。在生产部署之外验证和调试策略，其中语法错误可能会导致停机，错误应用的授权可能会对安全性或可用性产生负面影响。
3.3.1. 查看现有策略
通常存在于 /etc/$service 目录中的服务策略文件。例如，计算(nova)的 policy.json 文件的完整路径为 /etc/nova/policy.json。
有两个重要的架构更改会影响如何查找现有策略：
Red Hat OpenStack Platform 现已容器化。
如果您从服务容器内部查看策略文件，则策略文件位于传统路径中：
/etc/$service/policy.json
如果您从服务容器以外查看策略文件，则策略文件位于以下路径中：
/var/lib/config-data/puppet-generated/$service/etc/$service/policy.json
每个服务都有代码中提供的默认策略，只有您手动创建的文件或使用
oslopolicy工具生成时可用。要生成策略文件，请使用容器中的oslopolicy-policy-generator，如下例所示：podman exec -it keystone oslopolicy-policy-generator --namespace keystone
默认情况下，生成的策略会按照 osly.policy CLI 工具推送到 stdout。
3.3.2. 了解服务策略
服务策略文件语句是别名定义或规则。别名定义存在于文件的顶部。以下列表包含计算(nova)生成的 policy.json 文件中的别名定义说明：
"context_is_admin": "role:admin"
当
rule:context_is_admin出现在目标后，策略会在允许用户在允许该操作前使用管理上下文检查操作。"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
当
admin_or_owner出现在目标后，策略会检查用户是否为管理员，或者其项目 ID 与目标对象的所属项目 ID 匹配，然后允许该操作。"admin_api": "is_admin:True
当
admin_api出现在目标后，策略会在允许用户在允许该操作前检查该用户。
3.3.3. 策略语法
policy.json 文件支持某些 operator，以便您可以控制这些设置的目标范围。例如，以下 keystone 设置中包含只有 admin 用户可以创建用户的规则：
"identity:create_user": "rule:admin_required"
: 字符左侧的 部分描述了特权，右侧部分定义谁可以使用特权。您还可以在右侧使用 Operator 来进一步控制范围：
-
!- 没有用户（包括管理员）可以执行此操作。 -
@和""- 任何用户都可以执行此操作。 -
不是、- 标准 operator 功能可用。和
例如，以下设置表示没有用户创建新用户的权限：
"identity:create_user": "!"
3.3.4. 使用策略文件进行访问控制
要覆盖默认规则，请编辑相应 OpenStack 服务的 policy.json 文件。例如，Compute 服务在 nova 目录中有一个 policy.json，这是容器内部查看容器化服务文件的正确位置。
- 在在生产环境中实施策略文件前，您必须对策略文件进行全面测试。
-
您必须检查对访问控制策略的任何更改都不会意外弱弱任何资源的安全性。另外，对
policy.json文件的任何更改都会立即有效，不需要重启服务。
3.3.4.1. 示例：创建高级用户角色
要自定义 keystone 角色的权限，请更新服务的 policy.json 文件。这意味着您可以更精细地定义分配给一类用户的权限。这个示例为您的部署创建一个 power 用户角色，其具有以下权限：
- 启动实例。
- 停止实例。
- 管理附加到实例的卷。
此角色的意图是为某些用户授予额外权限，而无需授予 admin 访问权限。要使用这些权限，您必须将以下权限授予自定义角色：
-
Start an instance:
"os_compute_api:servers:start": "role:PowerUsers" -
Stop an instance:
"os_compute_api:servers:stop": "role:PowerUsers" -
配置实例以使用特定卷："
os_compute_api:servers:create:attach_volume": "role:PowerUsers" -
列出附加到实例的卷："
os_compute_api:os-volumes-attachments:index": "role:PowerUsers" -
Attach a volume:
"os_compute_api:os-volumes-attachments:create": "role:PowerUsers" -
查看附加卷的详情："
os_compute_api:os-volumes-attachments:show": "role:PowerUsers" -
更改附加到实例的卷："
os_compute_api:os-volumes-attachments:update": "role:PowerUsers" -
删除附加到实例的卷："
os_compute_api:os-volumes-attachments:delete": "role:PowerUsers"
当修改 policy.json 文件时，会覆盖默认策略。因此，PowerUsers 的成员是唯一可以执行这些操作的用户。要允许 admin 用户保留这些权限，您可以为 admin_or_power_user 创建规则。您还可以使用一些基本条件逻辑来定义 role:PowerUsers 或 role:Admin。
要确保在命令行会话中使用 keystone v3 API，提供定义 v3 端点和设置的 rc 文件：
OS_AUTH_URL=http://controller-hostname.lab.local:5000/v3 OS_USERNAME=username OS_PASSWORD=password OS_USER_DOMAIN_NAME=Default OS_PROJECT_DOMAIN_NAME=Default OS_PROJECT_NAME=project-name OS_IDENTITY_API_VERSION=3
创建自定义 keystone 角色：
$ openstack role create PowerUsers +-----------+----------------------------------+ | Field | Value | +-----------+----------------------------------+ | domain_id | None | | id | 7061a395af43455e9057ab631ad49449 | | name | PowerUsers | +-----------+----------------------------------+
将现有用户添加到角色，并将角色分配给项目：
$ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
注意角色分配专门用于一个项目。这意味着，当您为用户分配角色时，您还会同时定义 target 项目。如果您想要用户收到同一角色，但对于其他项目，则必须为它们单独分配角色，但针对不同的项目。
查看默认 nova 策略设置：
$ oslopolicy-policy-generator --namespace nova
通过将以下条目添加到
/etc/nova/policy.json，为新的PowerUsers角色创建自定义权限：注意在部署前测试您的策略更改，以验证它们是否按预期工作。
{ "os_compute_api:servers:start": "role:PowerUsers", "os_compute_api:servers:stop": "role:PowerUsers", "os_compute_api:servers:create:attach_volume": "role:PowerUsers", "os_compute_api:os-volumes-attachments:index": "role:PowerUsers", "os_compute_api:os-volumes-attachments:create": "role:PowerUsers", "os_compute_api:os-volumes-attachments:show": "role:PowerUsers", "os_compute_api:os-volumes-attachments:update": "role:PowerUsers", "os_compute_api:os-volumes-attachments:delete": "role:PowerUsers" }保存此文件时，更改将立即生效。添加到
PowerUserskeystone 角色中的任何用户都会获得这些权限。
3.3.4.2. 示例：根据属性限制访问权限
您可以根据用户发出 API 调用的属性，创建限制对 API 调用的访问的策略。例如，以下默认规则指出，如果从管理上下文运行，则允许删除密钥对，或者令牌的用户 ID 与与目标关联的用户 ID 匹配。
"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"
注意：* 全新实施的功能并不能保证每个版本都处于每个服务中。因此，务必要使用目标服务的现有策略的惯例编写规则。有关查看这些策略的详情，请参阅 检查现有策略。* 所有策略都应该在将部署的每个版本的非生产环境中进行测试，因为无法保证跨版本的兼容性策略。
根据上述示例，您可以制作 API 规则根据是否拥有资源来展开或限制用户的访问权限。另外，属性可以与其他限制相结合，组成规则，如下例所示：
"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
请参考上面的示例，您可以为管理员和用户创建一个唯一规则，然后使用该规则进一步限制操作：
"admin_or_user": "is_admin:True or user_id:%(user_id)s" "os_compute_api:os-instance-actions": "rule:admin_or_user"
有关可用的 policy.json 语法选项的更多信息，请参阅 策略语法。
3.3.4.3. 查看角色分配
生成角色分配报告：
openstack role assignment list --names +---------------+--------------------+-------+----------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +---------------+--------------------+-------+----------------------+--------+-----------+ | admin | glance@Default | | services@Default | | False | | admin | ceilometer@Default | | services@Default | | False | | ResellerAdmin | ceilometer@Default | | services@Default | | False | | PowerUsers | demo-user@Default | | demo-project@Default | | False | | admin | swift@Default | | services@Default | | False | | admin | aodh@Default | | services@Default | | False | | admin | neutron@Default | | services@Default | | False | | admin | nova@Default | | services@Default | | False | | _member_ | demo@Default | | demo@Default | | False | | admin | cinder@Default | | services@Default | | False | | admin | admin@Default | | admin@Default | | False | | admin | gnocchi@Default | | services@Default | | False | +---------------+--------------------+-------+----------------------+--------+-----------
查看特定用户的角色分配：
$ openstack role assignment list --user demo-user --project demo-project --names +-------------+----------------+-------+----------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +-------------+----------------+-------+----------------------+--------+-----------+ | PowerUsers | demo-user@Default | | demo-project@Default | | False | +-------------+----------------+-------+----------------------+--------+-----------+
3.4. 令牌
对用户进行身份验证后，将生成令牌以授权和访问 OpenStack 环境。令牌可以具有变量生命周期范围，但到期的默认值是一小时。推荐的过期值应设置为一个较低值，以便内部服务有足够的时间来完成任务。如果令牌在任务完成前过期，云可能会变得无响应或停止提供服务。在使用期间，计算服务将磁盘镜像传输到管理程序管理程序以进行本地缓存所需要的时间示例。
令牌通常在身份服务响应较大上下文的结构内传递。这些响应还提供各种 OpenStack 服务的目录。每个服务都列出其名称，以及内部、管理和公共访问权限的访问端点。身份服务支持令牌撤销。此清单作为用于撤销令牌的 API，列出已撤销的令牌和个别 OpenStack 服务，用于缓存令牌以查询已撤销的令牌，并将它们从缓存的已撤销令牌列表中删除。Fernet 令牌是 Red Hat OpenStack Platform 16.0 中唯一支持的令牌。
3.4.1. Fernet 令牌
Fernet 是明确设计为在 API 令牌中使用的安全消息传递格式。Fernet 令牌非持久性（不需要保留数据库）、轻量级（在 180 到 240 字节）并减少运行云所需的操作开销。身份验证和授权元数据捆绑到消息包的有效负载中，然后作为 Fernet 令牌加密并签名（在 180 到 240 字节）。
与 UUID 不同，PKI 和 PKIZ 令牌，Fernet 令牌不要求持久性。Keystone 令牌数据库不再作为身份验证的副作用造成 bloat。在使用 Fernet 令牌时，不再需要从令牌数据库修剪已到期的令牌。由于 Fernet 令牌是非持久性，因此不必复制它们。只要每个 Keystone 节点共享相同的存储库，您可以在节点间创建并验证 Fernet 令牌。
与 PKI 和 PKIZ 令牌相比，Fernet 令牌的大小会较小，通常保存在 250 字节限值下。对于 PKI 和 PKIZ 令牌，更大的服务目录会导致令牌长度较长。此模式不与 Fernet 令牌存在，因为加密有效负载的内容保持在最低程度。
有关 Fernet 令牌和轮转 Fernet 密钥的详情，请参考 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/deploy_fernet_on_the_overcloud/。
3.5. Keystone 域
Keystone 域是高级别安全界限，逻辑分组项目、用户和组。因此，它们可用于集中管理所有基于 Keystone 的身份组件。随着帐户域、服务器、存储和其他资源的引入，现在可逻辑分组为多个项目（以前称为称为租户），它们本身可以在主帐户容器下分组。此外，还可在帐户域内管理多个用户，并为每个项目分配不同的角色。
身份 V3 API 支持多个域。不同域的用户可能会在不同的身份验证后端表示。它们甚至可能具有不同的属性，它们必须映射到一组角色和特权，这些属性在策略定义中使用的，以访问各种服务资源。
如果规则可能仅指定管理员用户和属于项目的用户的访问权限，则映射可能很简单。在其他情况下，云管理员可能需要批准每个项目的映射例程。
特定于域的身份验证驱动程序允许使用特定域的配置文件为多个域配置身份服务。启用驱动程序并设置特定于域的配置文件位置，发生在 /var/lib/config-data/puppet-generated/keystone/keystone.conf 文件的 [identity] 部分中。例如：
[identity] domain_specific_drivers_enabled = True domain_config_dir = /var/lib/config-data/puppet-generated/keystone/etc/keystone/domains/
任何没有特定域配置文件的域都将在主 /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 文件中使用选项。
3.6. 使用身份服务迭代
联合身份是一种在身份提供商和服务提供程序(SP)之间建立信任的机制。在本例中，服务提供程序是由 OpenStack 云提供的服务。
对于身份验证和授权服务，OpenStack 身份模型将外部身份验证数据库视为单独的 Keystone 域。每个联合认证机制都与 keystone 域关联，支持多个共存域。您可以使用角色向外部域中的用户授予对云中资源的访问权限；这种方法也可以在跨域多项目部署中工作。这种方法还对每组件策略造成影响，因为并非所有 OpenStack 角色都可以映射到外部经过身份验证的用户。例如，如果外部身份验证数据库中的用户要求管理访问权限与 admin 域中的 用户类似，则通常会有其他配置和考虑。
admin
联合身份提供了一种使用现有凭证的方式，通过一组凭证在多个授权云中提供的多个端点（如服务器、卷和数据库）访问云资源，而无需多次置备额外的身份或登录。该凭据由用户的身份提供程序维护。
身份服务可以在 SQL 数据库中存储用户凭据，也可以使用与 LDAP 兼容的目录服务器。Identity 数据库可能与其他 OpenStack 服务使用的数据库分开，以减少被存储凭证的破坏的风险。
当您使用用户名和密码进行身份验证时，身份不会对密码强度、过期或失败的身份验证尝试强制执行策略。要强制使用更强大的密码策略的组织应考虑使用身份扩展或外部身份验证服务。
LDAP 简化了将身份身份验证集成到组织的现有目录服务和用户帐户管理流程中。OpenStack 中的身份验证和授权策略可能会委派给其他服务。典型的用例是寻求部署私有云的组织，已在 LDAP 系统中拥有员工和用户的数据库。使用此作为身份验证授权机构，对身份服务的请求被委派给 LDAP 系统，然后根据其策略授权或拒绝。身份验证成功后，身份服务会生成令牌，用于访问授权服务。
请注意，如果 LDAP 系统为用户定义了属性，如 admin、finance、HR 等用户，则必须将它们映射到身份中的角色和组，以供各种 OpenStack 服务使用。/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 文件将 LDAP 属性映射到身份属性。
3.7. 使用 Red Hat Single Sign-On 与 IdM 联合
您可以使用 Red Hat Single Sign-On (RH-SSO)来联合您的 IdM 用户进行 OpenStack 身份验证(authN)。通过联合，您的 IdM 用户无需向任何 OpenStack 服务公开凭证，即可登录 OpenStack 控制面板。相反，当仪表板需要用户凭证时，它会将用户转发到 Red Hat Single Sign-On (RH-SSO)，并允许他们输入其 IdM 凭证。因此，RH-SSO 断言回到控制面板，该用户已成功通过了身份验证，然后控制面板则允许用户访问该项目。
3.7.1. 联合工作流
本节论述了如何 keystone、RH-SSO 和 IdM 相互交互。OpenStack 中的联合使用身份提供程序和服务提供程序的概念：
Identity Provider (IdP)- 存储用户帐户的服务。在本例中，IdM 中保存的用户帐户将使用 RH-SSO 向 Keystone 呈现。
服务提供商 (SP)- 需要来自 IdP 中用户进行身份验证的服务。在本例中，keystone 是向 IdM 用户授予 Dashboard 访问权限的服务供应商。
在下图中，keystone (SP)与 RH-SSO ( IdP)通信，它提供了必要的 SAML2 WebSSO。RH-SSO 也可以作为其他 IdP 的通用适配器。在此配置中，您可以在 RH-SSO 上指向 keystone，RH-SSO 会将请求转发到它支持（称为身份验证模块）的身份提供商中，它们目前包括 IdM 和 Active Directory。这可以通过将服务提供商(SP)和身份提供程序(IdP)交换元数据来完成，然后每个系统管理员都做出信任决定。结果是 IdP 可以自信地进行断言，SP 就可以收到这些断言。
如需更多信息，请参阅联合指南： https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/federate_with_identity_service/
3.8. 与基于 LDAP 的服务集成
身份服务(keystone)可验证在基于 LDAP 的服务中存储的用户帐户，如 Microsoft Active Directory Domain Services (AD DS)和 Red Hat Identity Management (IdM)。在这种情况下，keystone 具有 LDAP 用户数据库身份验证的只读访问权限，并可通过分配给身份验证的帐户的 authZ 权限保留管理。authZ 功能（权限、角色、项目）仍由 keystone 执行，其中的权限和角色通过 keystone 管理工具分配给 LDAP 帐户。
3.8.1. LDAP 集成如何工作
在下图中，keystone 使用加密的 LDAPS 连接连接到 Active Directory 域控制器。当用户登录到 horizon 时，keystone 会收到提供的用户凭据，并将它们传递给 authZ 的 Active Directory。
有关将 OpenStack 与 AD DS 和 IdM 集成相关的信息，请参阅集成指南 ：https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/integrate_with_identity_service/
第 4 章 轮转服务帐户密码
您可以定期轮转服务帐户密码，以提高您的安全状况。
4.1. overcloud 密码管理概述
在 overcloud 上运行的 OpenStack 服务通过其身份服务(keystone)凭据进行身份验证。这些密码在初始部署过程中生成，并定义为 heat 参数。例如：
'MistralPassword',
'BarbicanPassword',
'AdminPassword',
'CeilometerMeteringSecret',
'ZaqarPassword',
'NovaPassword',
'MysqlRootPassword'
您可以使用工作流服务(mistral)工作流轮转服务帐户使用的密码。但是，如果密码在 DO_NOT_ROTATE 中列出，则不会轮转密码，如密钥加密密钥(KEK)和 Fernet 密钥：
DO_NOT_ROTATE_LIST = (
'BarbicanSimpleCryptoKek',
'SnmpdReadonlyUserPassword',
'KeystoneCredential0',
'KeystoneCredential1',
'KeystoneFernetKey0',
'KeystoneFernetKey1',
'KeystoneFernetKeys',
)
这些密码位于 DO_NOT_ROTATE 列表中，原因如下：
-
BarbicanSimpleCryptoKek- 更改此密码需要您重新加密所有 secret。 -
KeystoneFernetKey和KeystoneCredential- 存在独立的工作流来轮换这些。如需更多信息，请参阅 {defaultURL}/deploy_fernet_on_the_overcloud/sec-fernet#rotate_the_fernet_keys_using_mistral。
4.2. 轮转密码
使用以下步骤轮转符合条件的密码。下次运行 openstack overcloud deploy 命令完成堆栈更新时，会应用您轮转的密码更改。在环境文件中指定的任何密码都优先于使用此方法的密码更改。有关中断要求和服务影响的详情，请参考中断要求。
不要使用此流程轮转 swift 密码，因为目前不支持。
以 stack 用户身份，运行密码轮转工作流。这会轮转所有密码，除了
DO_NOT_ROTATE列表中的密码外：$ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud"}'如果只想轮转特定的密码，您可以使用
password_list。您还可以使用此方法在DO_NOT_ROTATE列表中轮转密码。例如：$ openstack workflow execution create tripleo.plan_management.v1.rotate_passwords '{"container": "overcloud", "password_list": ["SaharaPassword", "ManilaPassword"]}'The Workflow service Mistral workflow generates new passwords for the service accounts.
- 运行堆栈更新以应用新的密码。
您可以通过创建工作流来检索密码并查看新密码，然后查看输出：
创建新工作流，以检索密码。记录工作流的 ID：
$ openstack workflow execution create tripleo.plan_management.v1.get_passwords '{"container": "overcloud"}' +--------------------+---------------------------------------------+ | Field | Value | +--------------------+---------------------------------------------+ | ID | edcf9103-e1a8-42f9-85c1-e505c055e0ed | | Workflow ID | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a | | Workflow name | tripleo.plan_management.v1.rotate_passwords | | Workflow namespace | | | Description | | | Task Execution ID | <none> | | Root Execution ID | <none> | | State | RUNNING | | State info | None | | Created at | 2020-01-22 15:47:57 | | Updated at | 2020-01-22 15:47:57 | +--------------------+---------------------------------------------+使用工作流 ID 检查工作流状态。在继续操作前，您必须等到工作流的状态为
SUCCESS：$ openstack workflow execution show edcf9103-e1a8-42f9-85c1-e505c055e0ed +--------------------+---------------------------------------------+ | Field | Value | +--------------------+---------------------------------------------+ | ID | edcf9103-e1a8-42f9-85c1-e505c055e0ed | | Workflow ID | 8aa2ac9b-22ee-4e7d-8240-877237ef0d0a | | Workflow name | tripleo.plan_management.v1.rotate_passwords | | Workflow namespace | | | Description | | | Task Execution ID | <none> | | Root Execution ID | <none> | | State | SUCCESS | | State info | None | | Created at | 2020-01-22 15:47:57 | | Updated at | 2020-01-22 15:48:39 | +--------------------+---------------------------------------------+工作流完成后，使用以下命令检索密码：
openstack workflow execution output show edcf9103-e1a8-42f9-85c1-e505c055e0ed { "status": "SUCCESS", "message": { "AdminPassword": "FSn0sS1aAHp8YK2fU5niM3rxu", "AdminToken": "dTP0Wdy7DtblG80M54r4a2yoC", "AodhPassword": "fB5NQdRe37BaBVEWDHVuj4etk", "BarbicanPassword": "rn7yk7KPafKw2PWN71MvXpnBt", "BarbicanSimpleCryptoKek": "lrC3sGlV7-D7-V_PI4vbDfF1Ujm5OjnAVFcnihOpbCg=", "CeilometerMeteringSecret": "DQ69HdlJobhnGWoBC0jM3drPF", "CeilometerPassword": "qI6xOpofuiXZnG95iUe8Oxv5d", "CephAdminKey": "AQDGVPpdAAAAABAAZMP56/VY+zCVcDT81+TOjg==", "CephClientKey": "AQDGVPpdAAAAABAAanYtA0ggpcoCbS1nLeDN7w==", "CephClusterFSID": "141a5ede-21b4-11ea-8132-52540031f76b", "CephDashboardAdminPassword": "AQDGVPpdAAAAABAAKhsx630YKDhQrocS4o4KzA==", "CephGrafanaAdminPassword": "AQDGVPpdAAAAABAAKBojG+CO72B0TdBRR0paEg==", "CephManilaClientKey": "AQDGVPpdAAAAABAAA1TVHrTVCC8xQ4skG4+d5A==" } }
4.3. 中断要求
当您更改 overcloud 服务帐户的密码时，可能会发生中断要求和服务影响。
在堆栈更新过程中轮转密码后，旧密码将变为无效。因此，服务在经过了 HTTP 401 错误时无法使用，它会使新密码添加到服务配置设置中。
另外，您可能会在更改支持服务的密码时（包括 MySQL、RabbitMQ 和高可用性）时遇到短暂的中断。
第 5 章 加强基础架构和虚拟化
本节包含特定于组件的建议和信息。
5.1. 漏洞意识
您的操作步骤应该可以了解新的漏洞和安全更新。硬件和软件供应商通常宣布漏洞存在，并可能会提供解决方案和补丁来解决这些漏洞。
红帽产品安全团队维护站点，以帮助您了解安全更新：
除了跟踪更新外，您还需要确保您的流程和部署设计为能够安装定期安全更新。对于内核更新，这需要重新引导 Compute 和管理节点。在设计这些进程时，也应考虑实例安全更新，而托管 glance 镜像也应定期更新，以确保新创建的实例获取最新的更新。
5.2. 网络时间协议
您需要确保 Red Hat OpenStack Platform 集群中的系统在系统间具有准确且一致的时间戳。RHEL8 上的 Red Hat OpenStack Platform 支持 Chrony 进行时间管理。如需更多信息 ，请参阅使用 Chrony 套件配置 NTP。
5.2.1. 为什么一致时间很重要
整个组织的持续时间对于运营和安全需求都至关重要：
- 识别安全事件
- 持续计时可帮助您将事件的时间戳与受影响系统上的事件关联，以便您可以了解事件序列。
- 身份验证和安全系统
安全系统对时间偏移非常敏感，例如：
- 基于 kerberos 的验证系统可能会拒绝验证受时钟偏移机制影响的客户端。
- 传输层安全性(TLS)证书取决于时间的有效来源。如果客户端和服务器系统时间超过 Valid From date 范围，则到服务器 TLS 连接的客户端会失败。
- Red Hat OpenStack Platform services
- 某些核心 OpenStack 服务特别依赖于准确计时，包括高可用性(HA)和 Ceph。
5.2.2. NTP 设计
网络时间协议(NTP)以分层设计的形式进行组织。每个层称为 stratum。层次结构的顶部是 stratum 0 设备，如 atomic 时钟。在 NTP 层次结构中，stratum 0 设备为公开可用级别 1 和 stratum 2 NTP 时间服务器提供引用。
请勿将数据中心客户端直接连接到公开可用的 NTP stratum 1 或 2 服务器。直接连接数量会对公共 NTP 资源造成不必要的负担。相反，在您的数据中心中分配专用时间服务器，并将客户端连接到那个专用服务器。
配置实例，使其从专用时间服务器接收时间，而不是从所在的主机接收。
在 Red Hat OpenStack Platform 环境中运行的服务容器仍然接收它们所在的主机的时间。
5.2.3. Configuring NTP in Red Hat OpenStack Platform
使用 heat 在 undercloud 和 overcloud 节点上配置 NTP。
-
要使用 NTP 配置 undercloud，请在运行
openstack undercloud install命令前使用 undercloud.conf 中的undercloud_ntp_servers参数。对于 undercloud minion，使用minion_ntp_servers参数。有关更多信息，请参阅 Director 配置参数。 要使用 NTP 配置 overcloud，请使用以下参数作为示例：
parameter_defaults: TimeZone: 'US/Central' NtpServer: ['ntpserver01.example.com']
有关网络时间参数的更多信息，请参阅 Overcloud 参数 指南中的时间参数。
5.3. Compute
本节介绍计算(nova)的安全性注意事项。
5.3.1. OpenStack 中的虚拟机监控程序
当您评估系统管理程序平台时，请考虑将运行管理程序的硬件的支持性。此外，您还考虑了硬件中提供的附加功能以及如何支持这些功能作为 OpenStack 部署的一部分。为此，每个虚拟机监控程序都有自己的硬件兼容性列表(HCL)。在选择兼容硬件时，务必要首先从安全角度了解基于硬件的虚拟化技术非常重要。
5.3.1.1. 管理程序和裸机
务必要识别使用 Linux 容器或裸机系统与使用 KVM 等虚拟机监控程序之间的差别。具体来说，此安全指南的重点在于拥有管理程序和虚拟化平台。但是，如果您的实施需要使用裸机或容器化环境，您必须注意与部署该环境相关的特定区别。
对于裸机，请确保在重新置备和停用之前节点已正确清理数据。另外，在重复使用节点前，您必须提供确保硬件未被篡改或被破坏。更多信息请参阅 https://docs.openstack.org/ironic/queens/admin/cleaning.html
5.3.1.2. 管理程序内存优化
某些虚拟机监控程序使用内存优化技术，这些技术对客户机虚拟机过量使用内存。这是一个非常有用的功能，允许您部署非常高的计算集群。这种技术的方法是通过重复数据删除或共享内存页面共享的方法：当两台虚拟机在内存中有相同的数据时，它们会有一些优点。通常，这通过写时复制(COW)机制执行，如内核相同的页面合并(KSM)。这些机制容易受到安全攻击的影响：
- 内存重复数据系统容易受到侧信道攻击的影响。在学术研究中，攻击者可以分析内存访问时间，攻击者能够识别在邻居虚拟机上运行的软件包和版本，以及软件下载和其他敏感信息。因此，一个虚拟机可以推断一个有关另一个状态的信息，这可能不适用于多项目环境，而所有项目都值得信任或共享同一级别的信任级别
- 更重要的是，对 KSM 进行了演示 的行化类型攻击，以交叉虚拟机对可执行内存的修改。这意味着恶意实例可以获取对同一计算主机上其他实例的代码执行访问权限。
如果部署器需要强大的项目分离（与公共云和一些私有云一样，则部署器应禁用 KSM）：
- 要禁用 KSM，请参考 取消激活 KSM。
5.3.2. 虚拟化
5.3.2.1. 物理硬件(PCI Passthrough)
PCI 透传允许实例直接访问节点上的某一硬件。例如，这可用于允许实例访问视频卡或 GPU，为高性能计算提供计算统一设备架构(CUDA)。此功能存在两种类型的安全风险：直接内存访问和硬件内省。
直接内存访问(DMA)是允许某些硬件设备访问主机计算机中的任意物理内存地址的功能。视频卡通常具有此功能。但是，不应该为实例授予任意物理内存访问权限，因为这会完全查看主机系统和其他实例在同一节点上运行的其他实例。硬件供应商使用输入/输出内存管理单元(IOMMU)在这样的情形中管理 DMA 访问。您应该确认管理程序已配置为使用此硬件功能。
当实例对固件或其他设备部分进行恶意修改时，会出现硬件影响。由于此设备被其他实例或主机操作系统使用，恶意代码可以分散到这些系统中。最终结果是，一个实例可以在其安全区外运行代码。这是一项重大破坏，因为会更难以重置物理硬件的状态，并可能导致其他暴露于管理网络，比如访问管理网络。
由于风险和复杂性与 PCI 透传相关，它应默认禁用。如果对特定需要启用启用，则需要有适当的进程来帮助确保硬件在重复使用前清理。
5.3.2.2. 虚拟硬件(QEMU)
运行虚拟机时，虚拟硬件是一个软件层，为虚拟机提供硬件接口。实例使用此功能提供可能需要的网络、存储、视频和其他设备。考虑到这一点，您环境中的大多数实例都将独占使用虚拟硬件，但有一个需要直接访问硬件的次要程度。最好仅调配所需的硬件。例如，如果您不需要它，置备 CD 驱动器并不必要。
确认您的 iptables 已将默认策略配置为过滤网络流量，并考虑检查现有的规则集来了解每个规则，并确定是否需要扩展策略。
强制访问控制通过将 QEMU 进程的权限限制为仅需要的，从而限制对尝试攻击的影响。在 Red Hat OpenStack Platform 上，SELinux 配置为在单独的安全上下文下运行每个 QEMU 进程。已预先配置了 Red Hat OpenStack Platform 服务的 SELinux 策略。
OpenStack 的 SELinux 策略旨在帮助保护管理程序主机和虚拟机免受两个主要威胁：
- 虚拟机监控程序威胁 - 虚拟机内运行的应用程序会攻击虚拟机监控程序访问底层资源。例如，当虚拟机可以访问管理程序操作系统、物理设备或其他应用程序时。这个威胁向量代表了大量风险，因为虚拟机监控程序上的危害可能会破坏物理硬件以及公开其他虚拟机和网络段。
- 虚拟机（多项目）威胁 - 在虚拟机内运行的应用程序会攻击管理程序访问或控制另一个虚拟机及其资源。这是虚拟化的唯一威胁，并代表了由于单个应用程序中的漏洞而受到大量虚拟机文件镜像受到危害的可能性。此虚拟网络攻击是主要关注点，因为用于保护实际网络的管理技术不会直接应用到虚拟环境。每个基于 KVM 的虚拟机都是一个由 SELinux 标记的进程，可有效地为每个虚拟机建立安全边界。这个安全边界由 Linux 内核监控和强制执行，以限制虚拟机对边界之外的资源的访问权限，如主机机器数据文件或其他虚拟机。
无论虚拟机中运行的客户机操作系统如何，红帽基于 SELinux 的隔离均提供。可以使用 Linux 或 Windows 虚拟机。
5.3.2.3. 标签和类别
基于 KVM 的虚拟机实例使用自己的 SELinux 数据类型进行标记，称为 svirt_image_t。内核级别保护可防止未经授权的系统进程（如恶意软件）操作磁盘上的虚拟机镜像文件。虚拟机关闭后，镜像存储为 svirt_image_t，如下所示：
system_u:object_r:svirt_image_t:SystemLow image1 system_u:object_r:svirt_image_t:SystemLow image2 system_u:object_r:svirt_image_t:SystemLow image3 system_u:object_r:svirt_image_t:SystemLow image4
svirt_image_t 标签 在磁盘上唯一标识镜像文件，允许 SELinux 策略限制访问。当基于 KVM 的计算映像开机时，SELinux 会将随机数字标识符附加到镜像中。SELinux 能够为每个管理程序节点最多 524,288 个虚拟机分配数字标识符，但大多数 OpenStack 部署都不太可能遇到此限制。此示例显示 SELinux 类别标识符：
system_u:object_r:svirt_image_t:s0:c87,c520 image1 system_u:object_r:svirt_image_t:s0:419,c172 image2
5.3.2.4. SELinux 用户和角色
SELinux 管理用户角色.这些可以通过 -Z 标志或使用 semanage 命令来查看。在虚拟机监控程序上，只有管理员应该可以访问系统，并且应具有与管理用户和系统上的任何其他用户相关的适当上下文。
5.3.2.5. 容器化服务
某些服务（如 nova、glance 和 keystone）现在在容器内运行。这种方法有助于通过更轻松地将更新应用到服务，从而改进您的安全状况。在其自己的容器中运行每个服务还可提高同一裸机上共存的服务之间的隔离。在减少攻击面时，通过防止对相邻服务的访问，对攻击的任何服务都会有帮助。
挂载到容器中的主机上任何路径都可用作挂载点，以在容器和主机间传输数据（如果它们配置为 ro/rw）。
如果要更新任何配置文件，需要考虑一些管理实践，因为容器化服务具有临时性：
-
不要更新您在物理节点的主机操作系统上找到的任何配置文件，例如：
/etc/cinder/cinder.conf。这是因为容器化服务不引用此文件。 - 不要更新容器中运行的配置文件。这是因为重启容器后会丢失任何更改。
相反，如果您需要对容器化服务添加任何更改，则需要更新用于看到容器的配置文件。这些文件在初始部署期间由 puppet 生成，包含对运行云的重要敏感数据，并且应进行相应的处理。它们存储在 /var/lib/config-data/puppet-generated/ 中。例如：
-
keystone:
/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf -
cinder:
/var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf -
nova:
/var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf
容器重启后，对这些文件所做的任何更改都会应用。
5.3.3. 强化计算部署
任何 OpenStack 部署的主要安全问题之一就是围绕敏感文件的安全性和控制，如 /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf 文件。此配置文件包含许多敏感选项，包括配置详情和服务密码。所有此类敏感文件都应被授予严格的文件权限，并通过文件完整性监控(FIM)工具（如 AIDE）进行监控。这些实用程序将取目标文件处于已知良好状态的哈希，然后定期获取文件的新哈希值，并将其与已知良好的哈希进行比较。如果发现某一警报被意外修改，则可以创建警报。
可以通过将文件复制到文件中包含的目录并运行 ls -lh 命令来检查文件的权限。这将显示有权访问文件的权限、所有者和组，以及文件上次修改时间以及文件创建的时间等其他信息。
/var/lib/nova 目录保存关于给定 Compute 节点上的实例的信息。该目录应被视为敏感，且严格强制实施文件权限。另外，它应该定期备份，因为它包含与该主机关联的实例的信息和元数据。
如果您的部署不需要完整的虚拟机备份，请考虑排除 /var/lib/nova/instances 目录，因为它与该节点上运行的每个实例的合并空间相同。如果您的部署需要完整的虚拟机备份，则需要确保成功备份这个目录。
存储在 storage 子系统（例如，Ceph）用于块存储(cinder)卷中的数据也应被视为敏感性，因为如果网络或逻辑访问允许，则可以从存储子系统获取完整的虚拟机映像。
5.3.4. 减少硬件漏洞
OpenStack 在物理服务器硬件上运行，固有其本身的安全挑战。本章介绍了方法来缓解基于硬件的威胁和漏洞。
5.3.4.1. 强化 PCI 透传
PCI 透传可让您让实例直接访问主机上安装的特定物理硬件。对于许多网络功能虚拟化(NFV)用例，可能会发生这种情况。但是，需要考虑一些安全实践：
如果使用 PCI 透传，请考虑部署支持中断重新映射的硬件。否则，您需要启用 allow_unsafe_interrupts 设置，这可能使 Compute 节点无法中断恶意实例的注入攻击。
5.3.4.2. 安全强化管理控制台
很多服务器厂商都包括一个单独的管理控制台，可为您的服务器启用远程会话。考虑查看供应商规定为安全保护这一访问点的操作。
5.3.4.3. 固件更新
物理服务器使用复杂的固件来启用和操作服务器硬件和轻量管理卡，这些卡可能具有自己的安全漏洞，从而允许系统访问和中断。为解决这个问题，硬件供应商会发布固件更新，这些更新独立于操作系统更新。您需要一个运行安全性流程，它能定期检索、测试并实施这些更新，请注意固件更新通常需要重启物理主机才能生效。
5.4. 块存储
OpenStack Block Storage (cinder)是一种为自助服务提供软件（服务和库）的服务，负责管理持久块级存储设备。这会创建对块存储资源的按需访问，以用于计算(nova)实例。这通过将块存储池虚拟化到各种后端存储设备池（可以是软件实施或传统硬件存储产品）来创建软件定义型存储。这个功能的主要功能是管理块设备的创建、附加和分离。用户无需了解后端存储设备的类型或所在的位置。
计算实例使用行业标准存储协议（如 iSCSI、ATA over Ethernet 或 Fibre-Channel）存储和检索块存储。这些资源通过 OpenStack 原生标准 HTTP RESTful API 管理和配置。
5.4.1. 卷 Wiping
擦除块存储设备的方法有多种。传统的方法是将 lvm_type 设置为 thin，然后使用 volume_clear 参数。另外，如果使用卷加密功能，则在删除卷加密密钥时不需要卷 wiping。
在以前的版本中，使用 lvm_type=default 表示擦除。虽然这个方法仍有效，但不建议在设置安全删除时使用 lvm_type=default。
volume_clear 参数可以接受 0 或 shred 作为参数。零 会将单个零零写入设备。shred 操作将编写三个通过预先确定的位模式。
5.4.2. 强化块存储
本节包含增强 OpenStack 块存储安全性的实用建议。
5.4.2.1. 将配置文件的 user/group 所有权设置为 root/cinder
配置文件包含组件无缝运行所需的关键参数和信息。如果非特权用户有意或意外地修改或删除任何参数，或者文件本身会导致严重可用性问题，从而导致向其他最终用户拒绝服务。因此，此类关键配置文件的用户所有权必须设置为 root，而组所有权必须设置为 cinder。
使用以下命令，检查这些配置文件的用户和组所有权是否分别设置为 root 和 cinder：
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf | egrep "root cinder" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/api-paste.ini | egrep "root cinder" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/policy.json | egrep "root cinder" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/rootwrap.conf | egrep "root cinder"
5.4.2.2. 为配置文件设置严格权限
检查以下文件的权限是否已设置为 640 或 stricter。
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf $ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/api-paste.ini $ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/policy.json $ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/rootwrap.conf
5.4.2.3. 使用 keystone 进行身份验证
在 /var/lib/config-data/puppet-generated/cinder/cinder.conf 中，检查 [DEFAULT] 部分的 auth_strategy 的值是否已设置为 keystone，且没有auth。
5.4.2.4. 为身份验证启用 TLS
在 /var/lib/config-data/puppet-generated/cinder/cinder.conf 中，检查 [keystone_authenticate_uri 的 www_authenticate_uri 的值也被设置为一个以 https:// 开头的身份 API 端点，而 下的参数值也设置为 [keystone_authtoken] False。
5.4.2.5. 确保块存储使用 TLS 与 Compute 通信
在 cinder.conf 中，检查 [DEFAULT] 部分下的 glance_api_servers 的值是否设置为以 https:// 开始的值，并且参数 glance_api_insecure 的值设置为 False。
5.4.2.6. 确保用于 NFS 的 NAS 设备在强化的环境中运行
Block Storage 服务(cinder)支持 NFS 驱动程序，它的工作方式与传统的块存储驱动程序不同。
NFS 驱动程序实际上不允许实例访问块级别的存储设备。相反，在 NFS 共享上创建文件并映射到实例，这样可模拟块设备。
块存储服务通过控制创建 cinder 卷时的文件权限来支持此类文件的安全配置。Cinder 配置也可以控制文件操作是否以 root 用户身份运行，还是以当前 Red Hat OpenStack Platform 进程用户身份运行。
有几个 director heat 参数控制 NFS 后端还是 NetApp NFS Block Storage 后端是否支持一个名为 NAS 的 NetApp 功能：
- CinderNetappNasSecureFileOperations
- CinderNetappNasSecureFilePermissions
- CinderNasSecureFileOperations
- CinderNasSecureFilePermissions
红帽不推荐启用此功能，因为它不会影响正常卷操作。director 会默认禁用这个功能，Red Hat OpenStack Platform 不支持它。
使用特定供应商驱动程序集成的 NAS 设备应被视为敏感且应在强化隔离的环境中部署。这些设备的任何破坏都可能导致访问或修改实例数据。
检查
cinder.conf文件的[DEFAULT]部分中的nas_secure_file_permissions的值是否已设置为auto。当
nas_secure_file_permissions参数设置为auto时，块存储服务会检测到是否存在现有的 cinder 卷：-
如果没有现有卷，cinder 将 选项设置为
True，并使用安全文件权限。 -
如果 cinder 检测到现有卷，cinder 将 选项设置为
False，并使用不安全的处理文件权限方法。
-
如果没有现有卷，cinder 将 选项设置为
检查
cinder.conf文件中的[DEFAULT]部分中的nas_secure_file_operations参数是否已设置为auto。当
nas_secure_file_operations参数设置为auto时，块存储服务会检测到是否存在现有的 cinder 卷：-
如果没有现有卷，cinder 将 选项设置为
True，且不会以 root 用户身份运行。 -
如果 cinder 检测到现有卷，cinder 将 选项设置为
False，并使用当前以root用户身份运行操作的方法。
-
如果没有现有卷，cinder 将 选项设置为
对于新安装，块存储服务会创建一个标志文件，以便在后续重启块存储服务时记住原始的决定。
5.4.2.7. 为请求正文设置最大大小
如果没有定义每个请求的最大正文大小，攻击者可以对大大小进行任意 OSAPI 请求，从而导致服务崩溃，最终导致服务攻击。分配最大值可确保任何恶意修改的请求都会阻止确保服务的持续可用。
检查 cinder.conf 中的 [DEFAULT] 部分的 osapi_max_request_body_size 是否已设置为 114688，或者在 cinder.conf 中的 [oslo_middleware] 部分的 max_request_body_size 被设置为 114688。
5.4.2.8. 启用卷加密
未加密的卷数据使托管平台成为攻击者尤为高价值的目标，因为它允许攻击者读取多个不同虚拟机的数据。另外，物理存储介质可能被滞后、重新挂载并从不同的计算机访问。加密卷数据和卷备份可帮助缓解这些风险，并为卷托管平台提供防御性深度。在将卷加密到磁盘前，块存储(cinder)能够加密卷数据，因此请考虑启用卷加密，并将 Barbican 用于私钥存储。
5.5. 网络
OpenStack 网络服务(neutron)使最终用户或项目能够定义和使用网络资源。除了编排网络配置外，OpenStack 网络还提供面向项目的 API，用于为云中的实例定义网络连接和 IP 寻址。过渡到以 API 为中心的联网服务后，云架构师和管理员应考虑保护物理网络基础架构和服务的良好做法。
OpenStack 网络设计为一个插件架构，通过开源社区或第三方服务提供 API 的可扩展性。在评估您的架构设计需求时，务必要确定 OpenStack 网络核心服务中提供的哪些功能、第三方产品所提供的任何其他服务，以及在物理基础架构中实施哪些补充服务。
本节是实施 OpenStack 网络时应考虑哪些流程和良好实践的高级概述。
5.5.1. 网络架构
OpenStack 网络是一种独立服务，可在多个节点上部署多个进程。这些进程与其他 OpenStack 服务和其他 OpenStack 服务交互。OpenStack 网络服务的主要进程是 neutron-server，它是一个 Python 守护进程，它公开 OpenStack 网络 API，并将项目请求传递到一组用于额外处理的插件。
OpenStack 网络组件包括：
-
Neutron 服务器(
neutron-server和neutron-*-plugin) - neutron-server 服务在 Controller 节点上运行，以服务网络 API 及其扩展（或插件）。它还强制执行每个端口的网络模型和 IP 寻址。neutron-server 需要直接访问持久数据库。代理可通过 neutron-server 间接访问数据库，以便使用 AMQP （高级消息队列协议）进行通信。 - Neutron 数据库 - 数据库是 neutron 信息的集中式来源，API 会记录数据库中的所有事务。这允许多个 Neutron 服务器共享同一个数据库集群，将它们保持同步，并允许持久性网络配置拓扑。
-
插件代理(
neutron-*-agent) - 在每个计算节点上运行，以及 L3 和 DHCP 代理（与 L3 和 DHCP 代理一致）来管理本地虚拟交换机(vswitch)配置。enabled 插件决定启用哪些代理。这些服务需要消息队列访问，具体要看所使用的插件、访问外部网络控制器或 SDN 实施。某些插件，如 OpenDaylight (ODL)和 Open Virtual Network (OVN)，不需要计算节点上任何 python 代理，只需要为集成需要启用的 Neutron 插件。 -
DHCP 代理(
neutron-dhcp-agent) - 为项目网络提供 DHCP 服务。这个代理在所有插件中都相同，它负责维护 DHCP 配置。neutron-dhcp-agent 需要消息队列访问。根据插件的可选功能。 -
元数据代理(
neutron-metadata-agent,neutron-ns-metadata-proxy) - 提供用于应用实例操作系统配置和用户提供的初始脚本（用户数据）的元数据服务。实施需要 L3 或 DHCP 代理命名空间中运行的neutron-ns-metadata-proxy截获 cloud-init 发送的元数据 API 请求，以代理到元数据代理。 -
L3 代理(
neutron-l3-agent) - 为项目网络上虚拟机的外部网络访问提供 L3/NAT 转发。需要消息队列访问。根据插件的可选功能。 - 网络提供程序服务(SDN server/services) - 为项目网络提供额外的网络服务。这些 SDN 服务可以通过 REST API 等通信通道与 neutron-server、neutron-plugin 和 插件代理交互。
下图显示了 OpenStack 网络组件的架构和网络流程图：
请注意，当使用分布式虚拟路由(DVR)和第 3 层高可用性(L3HA)时，这种方法会有很大变化。这些模式会改变 neutron 的安全状况，因为 L3HA 在路由器之间实现 VRRP。部署需要正确调整并强化，以帮助缓解对路由器的 DoS 攻击，而且路由器之间的本地网络流量必须被视为敏感，以帮助解决 VRRP 欺骗的威胁。DVR 将网络组件（如路由）移到 Compute 节点，同时仍然需要网络节点。因此，计算节点需要访问公共网络或从公共网络进行访问，增加其暴露，并要求客户进行额外的安全性考虑，因为需要确保防火墙规则和安全模型支持此方法。
5.5.1.1. Neutron 服务在物理服务器上放置
本节介绍了包括控制器节点、网络节点以及一组用于运行实例的计算节点的标准架构。要为物理服务器建立网络连接，典型的 neutron 部署最多可有四个不同的物理数据中心网络：
- 管理网络 - 用于 OpenStack 组件之间的内部通信。此网络上的 IP 地址应该只能在数据中心访问，并被视为管理安全区域。默认情况下，管理网络角色由 内部 API 网络执行。
- 客户机网络 - 用于云部署中的虚拟机数据通信。此网络的 IP 寻址要求取决于所使用的 OpenStack 网络插件，以及项目所提出的虚拟网络的网络配置选择。此网络被视为客户机安全区域。
- 外部网络 - 在一些部署场景中用于为虚拟机提供互联网访问功能。此网络上的 IP 地址应该可以被 Internet 上的任何人访问。此网络被视为在公共安全区中。该网络由 neutron External networks 提供。这些 neutron VLAN 托管在外部网桥上。它们不是由 Red Hat OpenStack Platform director 创建，而是在部署后由 neutron 创建。
- 公共 API 网络 - 将所有 OpenStack API （包括 OpenStack 网络 API）公开给项目。此网络上的 IP 地址应该可以被 Internet 上的任何人访问。这可能与外部网络相同，因为可以为外部网络创建子网，它使用 IP 分配范围小于 IP 块中的完整 IP 地址范围。此网络被视为在公共安全区中。
建议您将此流量划分为不同的区。如需更多信息，请参见下一节。
5.5.2. 使用安全区
建议您使用安全区的概念来保持关键系统相互独立。实际上，这意味着使用 VLAN 和防火墙规则隔离网络流量。这应该以更细致的方式完成，结果应该是只有需要连接到 neutron 的服务才能这样做。
在下图中，您可以看到创建了该区来分离某些组件：
- 仪表板：可以访问公共网络和管理网络。
- Keystone：可以访问管理网络。
- Compute 节点：可以访问管理网络和计算实例。
- 网络节点：根据使用的 neutron-plugin，可以访问管理网络、计算实例和可能公共网络。
- SDN 服务节点：管理服务、计算实例和可能公开，具体取决于所使用的产品和配置。
.
5.5.3. 网络服务
在设计 OpenStack 网络基础架构的初始架构阶段，需要确保适当的专业知识可用于协助设计物理网络基础架构，以识别正确的安全控制和审计机制。
OpenStack 网络添加虚拟化网络服务的一层，使项目能够构建自己的虚拟网络。目前，这些虚拟化服务不再像传统网络对应者一样成熟。在采用这些虚拟化服务的当前状态时，请考虑这些虚拟化服务的当前状态，因为它决定在虚拟化和传统网络界限时必须实施哪些控制。
5.5.3.1. 使用 VLAN 和隧道的 L2 隔离
OpenStack 网络可以采用两种不同的机制来对各个项目/网络隔离进行流量隔离：VLAN (IEEE 802.1Q 标记)或者使用 VXLAN 或 GRE 封装的 L2 隧道。OpenStack 部署的范围和规模决定了用于流量隔离或隔离的方法。
5.5.3.2. VLANs
VLAN 将作为带有特定 VLAN ID (VID)字段值的特定物理网络上的数据包实现。共享同一物理网络的 VLAN 网络相互隔离 L2，甚至可以有重叠的 IP 地址空间。支持 VLAN 网络的每个不同物理网络都被视为单独的 VLAN 中继，但有不同的 VID 值空间。有效的 VID 值是 1 到 4094。
VLAN 配置复杂性取决于您的 OpenStack 设计要求。要允许 OpenStack 网络更有效地使用 VLAN，您必须分配 VLAN 范围（每个项目一个），并将每个 Compute 节点物理交换机端口转换为 VLAN 中继端口。
如果您希望网络支持超过 4094 项目，则建议通过 VLAN 进行 L2 隧道配置。
5.5.3.3. L2 隧道
网络隧道将各个项目/网络与唯一的"tunnel-id"封装在一起，用于标识属于该组合的网络流量。项目的 L2 网络连接独立于物理本地或底层网络设计。通过封装 IP 数据包中的流量，流量可以跨第 3 层边界，免除了预先配置的 VLAN 和 VLAN 中继的需求。隧道为网络流量增加了一个模糊的层，从而降低了监控点上各个项目流量的可视性。
OpenStack 网络目前支持 GRE 和 VXLAN 封装。提供 L2 隔离的技术选择取决于要在部署中创建的项目网络的范围和大小。
5.5.3.4. 网络服务
项目网络隔离的选择会影响为项目服务实施网络安全性和控制边界。以下附加网络服务可用或当前处于开发阶段，以增强 OpenStack 网络架构的安全性形象。
5.5.3.5. 访问控制列表
计算支持利用 OpenStack 网络服务来项目网络流量访问控制。安全组允许管理员和项目指定流量的类型，以及允许通过虚拟接口端口传递的方向(ingress/egress)。安全组规则是有状态 L2-L4 流量过滤器。
5.5.4. L3 路由和 NAT
OpenStack 网络路由器可以连接多个 L2 网络，也可提供将一个或多个私有 L2 网络连接到共享外部网络（如用于访问互联网的公共网络）的网关。
L3 路由器在将路由器链接到外部网络的网关端口上提供基本的网络地址转换(SNAT 和 DNAT)功能。此路由器 SNAT （源 NAT）默认所有出口流量，并且支持浮动 IP，这将创建一个静态一对一的双向映射，从外部网络上的公共 IP 映射到与路由器附加的其他子网之一的专用 IP。浮动 IP （通过 DNAT）为实例提供外部入站连接，可以从一个实例移动到另一个实例。
考虑使用每个项目 L3 路由和浮动 IP，以更精细地连接项目实例。特别考虑应当提供给连接到公共网络或使用浮动 IP 的实例。建议谨慎对安全组的使用过滤对需要外部公开的服务的访问。
5.5.5. 服务质量(QoS)
默认情况下，服务质量(QoS)策略和规则由云管理员管理，这会导致项目无法创建特定的 QoS 规则，或者将特定的策略附加到端口。在一些用例中，如某些电信应用程序，管理员可能信任项目，从而使他们创建并把自己的策略附加到端口。这可以通过修改 policy.json 文件来完成。
从 Red Hat OpenStack Platform 12，neutron 支持入站和出站流量的带宽限制 QoS 规则。这个 QoS 规则命名为 QosBandwidthLimitRule，它接受以每秒 kilobits 测量的两个非负整数：
-
max-kbps: bandwidth -
max-burst-kbps: burst buffer
QoSBandwidthLimitRule 已在 neutron Open vSwitch、Linux 网桥和 SR-IOV 驱动程序中实施。但是，对于 SR-IOV 驱动程序，不会使用 max-burst-kbps 值，并在设置时忽略。
在 Red Hat OpenStack Platform 10 (Newton)发行版中添加了 QoS 规则 QosDscpMarkingRule。此规则标记 IPv4 (RFC 2474)上服务标头类型中的不同 Service Code Point (DSCP)值，并在离开虚拟机的所有流量的 IPv6 上标记流量类标头，其中的规则会被应用。这是一个带有 21 个有效值的 6 位标头，它表示数据包的 drop 优先级应跨网络符合拥塞。防火墙也可以使用它来与其访问控制列表匹配有效或无效流量。
5.5.5.1. 负载平衡
OpenStack 负载均衡服务(Octavia)为红帽 OpenStack 平台 director 安装提供负载平衡即服务(LBaaS)实施。要实现负载均衡，Octavia 支持启用多个供应商驱动程序。引用供应商驱动程序(Amphora provider driver)是一个开源、可扩展和高度可用的负载均衡供应商。它通过管理一组虚拟机来完成负载平衡服务交付，其中统称为 amphorae-它可按需启动。
有关负载平衡服务的更多信息，请参阅网络指南中的使用 Octavia 进行负载平衡即服务(LBaaS)。
5.5.6. 强化网络服务
本节讨论 OpenStack 网络配置良好的实践，因为它们适用于 OpenStack 部署中的项目网络安全性。
5.5.6.1. 限制 API 服务器的绑定地址：neutron-server
要限制 OpenStack Networking API 服务为传入客户端连接绑定网络套接字的接口或 IP 地址，请在 /var/lib/config-data/puppet-generated/neutron/neutron/neutron.conf 文件中指定 bind_host 和 bind_port ：
# Address to bind the API server bind_host = IP ADDRESS OF SERVER # Port the bind the API server to bind_port = 9696
5.5.6.2. 限制 OpenStack 网络服务的 DB 和 RPC 通信
OpenStack 网络服务的各种组件使用消息传递队列或数据库连接与 OpenStack 网络中其他组件通信。
建议您按照 ??? 中所有需要 RPC 通信的组件提供的指南进行操作。
5.5.6.3. 项目网络服务工作流
OpenStack 网络为用户提供网络资源的自助配置。重要的是，云架构师和操作员可以评估其设计用例，从而让用户能够创建、更新和销毁可用的网络资源。
5.5.6.4. 网络资源策略引擎
OpenStack 网络中的策略引擎及其配置文件(policy.json)提供了在项目网络方法和对象上为用户提供精细的授权方法( policy.json)。OpenStack 网络策略定义会影响网络可用性、网络安全性和整体 OpenStack 安全。云架构师和操作员应认真评估其对用户和项目对网络资源的管理访问权限的策略。
查看默认网络资源策略非常重要，因为可以修改此策略以符合您的安全状况。
如果您的 OpenStack 部署提供了多个外部访问点到不同的安全区，请务必限制项目将多个 vNIC 附加到多个外部访问点的 vNIC 的功能会桥接这些安全区，并可能导致无法预见的安全危害。您可以使用计算提供的主机聚合功能，或者将项目实例拆分为具有不同虚拟网络配置的多个项目中来帮助缓解这一风险。有关主机聚合的更多信息，请参阅 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/instances_and_images_guide/ch-manage_instances#section-manage-host-aggregates。
5.5.6.5. 安全组
安全组是安全组规则的集合。安全组及其规则允许管理员和项目指定被允许通过虚拟接口端口的流量和方向(ingress/egress)的类型。在 OpenStack 网络中创建虚拟接口端口时，它将与安全组关联。可将规则添加到默认安全组中，以便逐个部署时更改行为。
当使用 Compute API 修改安全组时，更新的安全组将应用到实例上的所有虚拟接口端口。这是因为计算安全组 API 基于实例，而非基于端口的，如 neutron 中找到。
5.5.6.6. 配额
配额可用于限制项目可用的网络资源数量。您可以为所有项目实施默认配额。要查看配额选项，请参阅 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf。
OpenStack 网络还通过配额扩展 API 支持每个项目配额限制。要启用每个项目配额，您必须在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中设置 quota_driver 选项。例如：
quota_driver = neutron.db.quota_db.DbQuotaDriver
5.5.6.7. 缓解 ARP 欺骗
OpenStack 网络具有内置功能，有助于缓解对实例的 ARP 欺骗的威胁。除非为产生的风险给出谨慎考虑，否则不应禁用此项。
5.5.6.8. 将配置文件的 user/group 所有权设置为 root/neutron
配置文件包含组件无缝运行所需的关键参数和信息。如果非特权用户，意外或意外修改或删除任何参数或者文件本身会导致严重可用性问题，从而导致向其他最终用户拒绝服务。因此，此类关键配置文件的用户所有权必须设置为 root，而组所有权必须设置为 neutron。
确保以下文件的用户和组所有权分别设置为 root 和 neutron。请注意，具体文件路径可能因容器化服务而异：
$ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf | egrep "root neutron" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/api-paste.ini | egrep "root neutron" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/policy.json | egrep "root neutron" $ stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/rootwrap.conf | egrep "root neutron"
5.5.6.9. 为配置文件设置 Strict 权限
检查以下文件的权限是否已设置为 640 或 stricter。请注意，具体文件路径可能因容器化服务而异：
$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf $ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/api-paste.ini $ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/policy.json $ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/rootwrap.conf
5.5.6.10. 使用 Keystone 进行身份验证
在 /var/lib/config-data/puppet-generated/neutron/neutron/neutron.conf 中检查 [DEFAULT] 部分下的 auth_strategy 的值是否已设置为 keystone，且没有auth 或 noauth2。
5.5.6.10.1. 使用安全协议进行身份验证
在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中检查 [keystone_ authenticate _uri 的值是否已设置为 False。
5.5.6.10.2. 在 Neutron API 服务器中启用 TLS
在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中，确保 [DEFAULT] 部分下的参数 use_ssl 被设置为 True。
第 6 章 使用 director 配置安全强化
本章论述了如何在部署过程过程中应用安全强化值。
在运行 openstack overcloud deploy 时，请记住，除了您想要进行的任何更改外，您始终还需要包含部署 overcloud 所需的所有必要环境文件。
6.1. 使用 SSH 横幅文本
您可以设置向所有通过 SSH 连接的用户显示控制台消息的横幅。您可以使用环境文件中的以下参数向 /etc/issue 添加横幅文本。考虑自定义此示例文本以符合您的要求。
resource_registry:
OS::TripleO::Services::Sshd: ../puppet/services/sshd.yaml
parameter_defaults:
BannerText: |
******************************************************************
* This system is for the use of authorized users only. Usage of *
* this system may be monitored and recorded by system personnel. *
* Anyone using this system expressly consents to such monitoring *
* and is advised that if such monitoring reveals possible *
* evidence of criminal activity, system personnel may provide *
* the evidence from such monitoring to law enforcement officials.*
******************************************************************
要将此更改应用到部署，请将设置保存为名为 ssh_banner.yaml 的文件，然后将它传递给 overcloud deploy 命令，如下所示：& lt;full environment > 表示您必须仍包含所有原始部署参数。例如：
openstack overcloud deploy --templates \
-e <full environment> -e ssh_banner.yaml6.2. 审核系统事件
维护所有审计事件的记录可帮助您建立系统基准、执行故障排除或分析导致特定结果的事件序列。审计系统能够记录许多类型的事件，如更改系统时间、对 Mandatory/Discretionary Access Control 的更改，以及创建/删除用户或组。
可使用环境文件创建规则，这些文件随后由 director 注入到 /etc/audit/audit.rules 中。例如：
resource_registry:
OS::Tripleo::Services::AuditD: /usr/share/openstack-tripleo-heat-templates/deployment/auditd/auditd-baremetal-puppet.yaml
parameter_defaults:
AuditdRules:
'Record Events that Modify User/Group Information':
content: '-w /etc/group -p wa -k audit_rules_usergroup_modification'
order : 1
'Collects System Administrator Actions':
content: '-w /etc/sudoers -p wa -k actions'
order : 2
'Record Events that Modify the Systems Mandatory Access Controls':
content: '-w /etc/selinux/ -p wa -k MAC-policy'
order : 36.3. 管理防火墙规则
防火墙规则会部署期间自动应用于 overcloud 节点上，并且设计为仅公开获取 OpenStack 正常工作所需的端口。您可以根据需要指定其他防火墙规则。例如，要为 Zabbix 监控系统添加规则：
parameter_defaults:
ControllerExtraConfig:
tripleo::firewall::firewall_rules:
'301 allow zabbix':
dport: 10050
proto: tcp
source: 10.0.0.8
action: accept
您还可以添加限制访问的规则。规则定义中使用的数字将决定规则的优先级。例如，RabbitMQ 的规则编号默认为 109。如果要限制它，请将其切换以使用较低值：
parameter_defaults:
ControllerExtraConfig:
tripleo::firewall::firewall_rules:
'098 allow rabbit from internalapi network':
dport: [4369,5672,25672]
proto: tcp
source: 10.0.0.0/24
action: accept
'099 drop other rabbit access':
dport: [4369,5672,25672]
proto: tcp
action: drop
在这个示例中，098 和 099 是任意选择的数字，其小于 RabbitMQ 的规则编号 109。要确定规则的数量，您可以检查相应节点上的 iptables 规则；对于 RabbitMQ，您可以检查控制器：
iptables-save [...] -A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT
或者，您还可以从 puppet 定义中提取端口要求。例如，RabbitMQ 的规则存储在 puppet/services/rabbitmq.yaml 中：
tripleo.rabbitmq.firewall_rules:
'109 rabbitmq':
dport:
- 4369
- 5672
- 25672可以为规则设置以下参数：
-
端口：与该规则关联的端口。puppetlabs-firewall弃用。 -
dport：与该规则关联的目的地端口。 -
SPORT：与该规则关联的源端口。 -
探测：与 规则关联的协议。默认为 tcp -
操作：与该规则关联的操作策略。默认为 accept -
跳过：要跳转到的链。 -
State：与该规则关联的状态阵列。默认为 [NEW] -
Source：与该规则关联的源 IP 地址。 -
在iface 中：与规则关联的网络接口。 -
链链：与该规则关联的链。默认为 INPUT -
目的地：与该规则关联的目的地 cidr。 -
Extras：puppetlabs-firewall模块支持的任何其他参数的哈希。
6.4. 使用 AIDE 进行入侵检测
AIDE （高级入侵检测环境）是一个文件和目录完整性检查程序。它用于检测未经授权的文件修改或更改的事件。例如，如果更改了系统密码文件，AIDE 可以提醒您。
AIDE 通过分析系统文件，然后编译文件哈希完整性数据库来实现。然后，数据库充当一个比较点，以验证文件和目录的完整性并检测更改。
director 包括 AIDE 服务，允许您将条目添加到 AIDE 配置中，然后供 AIDE 服务用于创建完整性数据库。例如：
resource_registry:
OS::TripleO::Services::Aide: ../puppet/services/aide.yaml
parameter_defaults:
AideRules:
'TripleORules':
content: 'TripleORules = p+sha256'
order: 1
'etc':
content: '/etc/ TripleORules'
order: 2
'boot':
content: '/boot/ TripleORules'
order: 3
'sbin':
content: '/sbin/ TripleORules'
order: 4
'var':
content: '/var/ TripleORules'
order: 5
'not var/log':
content: '!/var/log.*'
order: 6
'not var/spool':
content: '!/var/spool.*'
order: 7
'not nova instances':
content: '!/var/lib/nova/instances.*'
order: 8上面的例子不是主动维护或基准测试的，因此您应该选择适合您的要求的 AIDE 值。
-
声明了一个名为
TripleORules的别名，以避免每次都重复出现相同的属性。 -
别名接收
p+sha256的属性。在 AIDE 术语中，这显示为以下指令：使用sha256完整性 checksum 来监控所有文件权限。
有关 AIDE 配置文件可用属性的完整列表，请参见 的 AIDE MAN 页面。https://aide.github.io/
要将此更改应用到您的部署，请将设置保存为名为 aide.yaml 的文件，然后将它传递给 overcloud deploy 命令，如下所示：& lt;full environment > 表示您必须仍包含所有原始部署参数。例如：
openstack overcloud deploy --templates -e <full environment> /usr/share/openstack-tripleo-heat-templates/environments/aide.yaml
6.4.1. 使用复杂的 AIDE 规则
可使用上述格式创建复杂的规则。例如：
MyAlias = p+i+n+u+g+s+b+m+c+sha512
以上将转换为以下指令：监控权限、索引节点、链接数目、用户、组、大小、块计数、mtime、ctime、ctime、ctime。
请注意，别名应始终具有 1 的顺序位置，这意味着它位于 AIDE 规则的顶部，并递归地应用于以下所有值。
别名后方是要监控的目录。请注意，可以使用正则表达式。例如，我们为 var 目录设置了监控，但使用 ! 和 '!/var/spool. *' 和 的 a not 子句覆盖。
'!/var/spool.*'
6.4.2. 其他 AIDE 值
还提供以下 AIDE 值：
AideConfPath ：到 aide 配置文件的完整 POSIX 路径，默认为 /etc/aide.conf。如果没有要求更改文件位置，则建议使用默认路径进行保留。
AideDBPath ：到 AIDE 完整性数据库的完整 POSIX 路径。这个值可以进行配置，使操作员能够声明自己的完整路径，因为 AIDE 数据库文件通常存储出节点可能位于只读文件挂载中。
AideDBTempPath ：AIDE 完整性临时数据库的完整 POSIX 路径。此临时文件在 AIDE 初始化新数据库时创建。
AideHour ：此值是将 hour 属性设置为 AIDE cron 配置的一部分。
AideMinute ：此值是将 minute 属性设置为 AIDE cron 配置的一部分。
AideCronUser ：此值是将 linux 用户设置为 AIDE cron 配置的一部分。
AideEmail ：此值设置每次运行 cron 时接收 AIDE 报告的电子邮件地址。
AideMuaPath ：此值设置邮件用户代理的路径，该代理用于将 AIDE 报告发送到在 AideEmail 中设置的电子邮件地址。
6.4.3. AIDE 的 Cron 配置
AIDE director 服务允许您配置 cron 作业。默认情况下，它将报告发送到 /var/log/audit/;；如果您想要使用电子邮件警报，则启用 AideEmail 参数，以将警报发送到配置的电子邮件地址。请注意，对于关键警报的电子邮件可能会受到系统中断的影响，并可能会受到不确定的消息过滤的影响。
6.4.4. 考虑系统升级的影响
执行升级时，AIDE 服务将自动重新生成新的完整性数据库，以确保正确计算所有升级的文件，以具有更新的校验和。
如果 openstack overcloud 部署 作为后续运行来调用到初始部署，并且会更改 AIDE 配置规则，则 director AIDE 服务将重建数据库，以确保新的配置属性封装在完整性数据库中。
6.5. 回顾 SecureTTY
securetty 允许您禁用任何控制台设备(tty)的 root 访问权限。此行为由 /etc/securetty 文件中的条目管理。例如：
resource_registry:
OS::TripleO::Services::Securetty: ../puppet/services/securetty.yaml
parameter_defaults:
TtyValues:
- console
- tty1
- tty2
- tty3
- tty4
- tty5
- tty66.6. 身份服务的 CADF 审计
全面的审计流程可帮助您审查 OpenStack 部署的持续安全状况。由于在安全模型中的角色，这对 keystone 来说尤其重要。
Red Hat OpenStack Platform 已将云审计数据 Federation (CADF)作为审计事件的数据格式，并且 keystone 服务为 Identity and Token 操作生成 CADF 事件。您可以使用 KeystoneNotificationFormat 为 keystone 启用 CADF 审计：
parameter_defaults:
KeystoneNotificationFormat: cadf6.7. 检查 login.defs 值
要强制新系统用户的密码要求（非keystone），director 可以根据以下示例参数在 /etc/login.defs 中添加条目：
resource_registry:
OS::TripleO::Services::LoginDefs: ../puppet/services/login-defs.yaml
parameter_defaults:
PasswordMaxDays: 60
PasswordMinDays: 1
PasswordMinLen: 5
PasswordWarnAge: 7
FailDelay: 4第 7 章 强化仪表板服务
本章论述了使用 OpenStack Dashboard (horizon)部署的 Red Hat OpenStack Platform 部署安全强化注意事项。
控制面板为用户提供一个自助服务门户，用于配置自己的资源（在管理员设定的限制范围内）。例如，您可以使用控制面板定义实例类别、上传虚拟机(VM)镜像、管理虚拟网络、创建安全组、启动实例，并通过管理控制台远程访问实例。
控制面板应当与 OpenStack API 相同的敏感度，因为这两个控制面板都能够授予云资源和配置的访问权限。
7.1. 规划仪表板部署
本节论述了部署 Dashboard (horizon)服务前需要考虑的安全方面。
7.1.1. 选择域名
建议您将仪表板部署到第二个级别域，如 https://example.com，而不是在共享子域（在任何级别）上部署仪表板，如 https://openstack.example.org 或 https://horizon.openstack.example.org。还建议您避免将仪表板部署到裸机内部域，如 https://horizon/。这些建议基于浏览器 相同-origin-policy 的限制。
这种方法可帮助您将 Cookie 和安全令牌与其他域隔离开来，其中您可能对内容有完全的控制。在子域上部署时，仪表板的安全等同于在同一第二个级别域中部署的最小安全应用程序。
您可以通过避免由 Cookie 支持的会话存储以及配置 HTTP Strict Transport Security (HSTS) （此指南中涉及）来进一步缓解这一风险。
7.1.2. 配置 ALLOWED_HOSTS
Web 服务可能会受到与虚假 HTTP 主机标头相关的威胁。为帮助缓解这种情况，请考虑将 ALLOWED_HOSTS 设置配置为使用 OpenStack 控制面板提供的 FQDN。
配置之后，如果传入 HTTP 请求的 Host: 标头中的值与此列表中的任何值不匹配，则会引发错误，请求者将无法继续。
Horizon 在 python Django Web 框架基础上构建，需要设置 ALLOWED_HOSTS 来防御可能对 HTTP Host: 标头的恶意操作。将此值设置为 FQDN，控制面板应可从以下位置访问。对于 director，此设置由 HorizonAllowedHosts 管理。
7.2. 了解常见 Web 服务器漏洞
本章论述了如何帮助缓解一些常见 Web 服务器漏洞。
7.2.1. 跨站点脚本(XSS)
OpenStack 控制面板可以自定义，并允许大多数字段中设置的整个 Unicode 字符；这种可扩展性可能会允许引入跨站点脚本(XSS)漏洞。Horizon 包括可帮助开发人员避免意外创建 XSS 漏洞的工具，但只有开发人员正确使用它们时才可以正常工作。建议您审计任何自定义仪表板，并特别注意以下功能：
-
mark_safe功能。 -
is_safe- 与自定义模板标签一起使用。 -
安全模板标签。 - 任何自动转义都关闭，并且任何可能会评估错误转义的数据的 JavaScript。
7.2.2. 跨站点请求 Forgery (CSRF)
OpenStack 仪表板旨在鼓励开发人员使用自定义仪表板引入跨站点脚本漏洞，因为存在潜在的威胁。使用多个 JavaScript 实例的仪表板应该被审核为漏洞，如不当使用 @csrf_exempt decorator。任何未遵循这些推荐安全设置的仪表板，都应仔细评估 CORS （跨 Origin 资源共享）限制。
您应该将 Web 服务器配置为为每个响应发送限制性 CORS 标头，仅允许仪表板域和协议。例如：Access-Control-Allow-Origin: https://example.com/。您不应该允许通配符来源。
7.2.3. Cross-Frame Scripting (XFS)
allowed _iframe_embed 设置不允许 Dashboard 嵌入到 iframe 中。旧浏览器仍容易受到不同的Frame 脚本编写(XFS)漏洞的影响，因此这个选项为不需要的部署添加额外的安全强化。
您可以使用以下参数允许 iframe 嵌入：
parameter_defaults:
ControllerExtraConfig:
horizon::disallow_iframe_embed: false7.2.4. 使用 HTTPS 加密进行仪表板流量
建议您使用 HTTPS 加密仪表板流量。为此，您可以将其配置为使用来自可识别的证书颁发机构(CA)的有效可信证书。只有当所有用户浏览器中预安装信任根时，私有机构签发的证书才合适。
配置 HTTP 请求到控制面板域，以重定向到完全限定的 HTTPS URL。
有关基于 director 的部署，请参阅 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud。
7.2.5. HTTP Strict Transport Security (HSTS)
HTTP 严格传输安全性(HSTS)可防止浏览器在最初进行安全连接后进行后续的不安全连接。如果您在公共或不可信区中部署了 HTTP 服务，HSTS 特别重要。
对于基于 director 的部署，默认启用此设置：
enable_secure_proxy_ssl_header: true
7.3. 缓存仪表板内容
7.3.1. 前端缓存
不建议在控制面板中使用前端缓存工具，因为它直接从 OpenStack API 请求呈现动态内容。因此，varnish 等前端缓存层可能会阻止显示正确的内容。控制面板使用 Django，它直接提供来自 Web 服务的静态介质，并且已经从 Web 主机缓存中受益。
7.3.2. 会话后端
对于基于 director 的部署，horizon horizon 的默认会话后端为 django.contrib.sessions.backends.cache，它与 memcached 结合使用。出于性能的原因，这个方法最好是本地内存缓存，对于高可用性和负载均衡安装更加安全，而且能够通过多个服务器共享缓存，同时仍然将其视为单一缓存。
您可以在 director 的 horizon.yaml 文件中查看这些设置：
horizon::cache_backend: django.core.cache.backends.memcached.MemcachedCache
horizon::django_session_engine: 'django.contrib.sessions.backends.cache'7.4. 查看 secret 密钥
控制面板依赖于一些安全功能的共享 SECRET_KEY 设置。secret 键应该是随机生成的字符串，长度至少为 64 个字符，必须在所有活跃的仪表板实例间共享。这个密钥的破坏可能会允许远程攻击者执行任意代码。轮转此键使现有用户会话和缓存无效。不要将此密钥提交到公共存储库。
对于 director 部署，此设置作为 HorizonSecret 值进行管理。
7.5. 配置会话 Cookie
控制面板会话 Cookie 可以打开以浏览器技术（如 JavaScript）进行交互。对于含有 TLS 的 director 部署，您可以使用 HorizonSecureCookies 设置强化此行为。
切勿将 CSRF 或会话 Cookie 配置为使用带有前导点的通配符域。
7.6. 静态介质
仪表板的静态介质应部署到仪表板域的子域，并由 Web 服务器提供。另外，也可以使用外部内容交付网络(CDN)。此子域不应设置 Cookie 或提供用户提供的内容。介质也应使用 HTTPS 提供。
仪表板的默认配置使用 django_compressor 在提供之前压缩和 minify CSS 和 JavaScript 内容。部署仪表板之前，应该静态执行这个过程，而不是使用默认的动态压缩方式，并将生成的文件与部署的代码或 CDN 服务器一起复制。在非生产构建环境中应进行压缩。如果这不实际，请考虑完全禁用资源压缩。不应在生产机器上安装在线压缩依赖关系（无，Node.js）。
7.7. 验证密码复杂性
OpenStack Dashboard (horizon)可以使用密码验证检查来强制实施密码复杂性。
您可以指定一个用于密码验证的正则表达式，以及为失败的测试显示帮助文本。以下示例要求用户在长度为 8 到 18 个字符之间创建密码：
parameter_defaults:
HorizonPasswordValidator: '^.{8,18}$'
HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'
要将此更改应用到部署，请将设置保存为名为 horizon_password.yaml 的文件，然后将它传递给 overcloud deploy 命令，如下所示：& lt;full environment > 表示您必须仍包含所有原始部署参数。例如：
openstack overcloud deploy --templates \
-e <full environment> -e horizon_password.yaml7.8. 强制管理员密码检查
默认情况下，以下设置被设置为 True，但在需要时可禁用它。
只有在潜在的安全影响被完全理解后，这些设置才应设置为 False。
控制面板中的 local_settings.py 文件中的 ENFORCE_PASSWORD_CHECK 设置显示 Change Password 表单上的 Admin Password 字段，这有助于验证管理员正在启动密码更改。
您可以使用环境文件禁用 ENFORCE_PASSWORD_CHECK ：
parameter_defaults:
ControllerExtraConfig:
horizon::enforce_password_check: false7.9. 不允许 iframe 嵌入
只有在潜在的安全影响被完全理解后，这些设置才应设置为 False。
DISALLOW_IFRAME_EMBED 设置不允许在 iframe 中嵌入 Dashboard。旧浏览器仍容易受到不同的Frame 脚本编写(XFS)漏洞的影响，因此这个选项为不需要的部署添加额外的安全强化。默认情况下，设置为 True，但可以根据需要使用环境文件禁用该设置。例如，您可以使用以下参数允许 iframe 嵌入：
parameter_defaults:
ControllerExtraConfig:
horizon::disallow_iframe_embed: false7.10. 禁用密码显示
默认情况下，以下设置被设置为 True，但在需要时可禁用它。
只有在潜在的安全影响被完全理解后，这些设置才应设置为 False。
通过密码显示按钮，可以在控制面板查看他们要输入的密码。可以使用 DISABLE_PASSWORD_REVEAL 参数切换这个选项：
parameter_defaults:
ControllerExtraConfig:
horizon::disable_password_reveal: false7.11. 显示仪表板的登录横幅
许多监管的行业，如 HIPAA、PCI-DSS 和 U.S。政府要求您显示用户登录横幅。仪表板服务在容器内运行，因此您将需要自定义 Dashboard 容器镜像来应用横幅。有关自定义 Dashboard 容器的更多信息，请参阅 https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/introduction_to_the_openstack_dashboard/index#dashboard-customization。
7.11.1. 自定义主题
在自定义 Dashboard 容器中，您可以通过手动编辑 /usr/share/openstack-dashboard/openstack_dashboard/themes/rcue/templates/auth/login.html 文件来创建 logon banner：
在
{% 包含 'auth/_login.html' %}部分前，输入所需的 logon 横幅。请注意，允许 HTML 标签。例如：<snip> <div class="container"> <div class="row-fluid"> <div class="span12"> <div id="brand"> <img src="../../static/themes/rcue/images/RHOSP-Login-Logo.svg"> </div><!--/#brand--> </div><!--/.span*--> <!-- Start of Logon Banner --> <p>Authentication to this information system reflects acceptance of user monitoring agreement.</p> <!-- End of Logon Banner --> {% include 'auth/_login.html' %} </div><!--/.row-fluid→ </div><!--/.container--> {% block js %} {% include "horizon/_scripts.html" %} {% endblock %} </body> </html>
更新的仪表板类似如下：
7.12. 限制文件上传的大小
您可以选择配置仪表板来限制文件上传的大小；此设置可能是各种安全强化政策的要求。
LimitRequestBody - 此值（以字节为单位）限制您可以使用控制面板传输的文件的最大大小，如镜像和其他大文件。
此设置没有被红帽正式测试。建议您在将此设置部署到生产环境前彻底测试此设置的影响。
如果值太小，则文件上传将失败。
例如，此设置限制每个文件上传的最大大小为 10 GB (10737418240)。您需要调整这个值以适应您的部署。
/var/lib/config-data/puppet-generated/horizon/etc/httpd/conf/httpd.conf<Directory /> LimitRequestBody 10737418240 </Directory>
/var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/10-horizon_vhost.conf<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
/var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/15-horizon_ssl_vhost.conf<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
这些配置文件由 Puppet 管理，因此每当运行 openstack overcloud deploy 过程时，任何非受管更改都会被覆盖。
7.13. 调试仪表板服务
建议您在生产环境中将 DEBUG 设置设为 False。如果设置为 True，则 Django 可能会将堆栈追踪输出到包含敏感 Web 服务器状态信息的浏览器用户。另外，DEBUG 模式可以禁用 ALLOWED_HOSTS，这可能是因为您的要求而意外的结果。
第 9 章 对象存储
Object Storage (swift)服务通过 HTTP 存储并检索数据。对象（大量数据）存储在组织层次结构中，可以配置为提供匿名的只读访问、ACL 定义的访问权限，甚至临时访问。Swift 支持通过中间件实施的多个基于令牌的身份验证机制。
应用使用行业标准 HTTP RESTful API 在对象存储中存储和检索数据。后端 swift 组件遵循相同的 RESTful 模型，但一些 API （如管理持久化）会分配到集群。
swift 的组件属于以下主要组：
- 代理服务
- 身份验证服务
存储服务
- 帐户服务
- 容器服务
- 对象服务
对象存储安装不必面向互联网，也可能是私有云，公共交换机是组织内部网络基础架构的一部分。
9.1. 网络安全性
swift 的安全强化开始保护网络组件的安全。如需更多信息，请参阅网络章节。
为获得高可用性，rsync 协议用于在存储服务节点之间复制数据。另外，代理服务在客户端端点和云环境之间转发数据时，代理服务与存储服务通信。
Swift 不通过节点间通信使用加密或身份验证。这是因为 swift 使用原生 rsync 协议来提高性能，且不会将 SSH 用于 rsync 通信。这就是您在架构图中看到私有交换机或专用网络([V]LAN)的原因。此数据区域也应当与其他 OpenStack 数据网络分开。
将私有(V) LAN 网络段用于数据区中的存储节点。
这要求代理节点具有双接口（物理或虚拟）：
- 个接口作为公共接口，供消费者使用。
- 另一个接口作为专用接口，可访问存储节点。
下图展示了一个可能的网络架构，它使用带管理节点(OSAM)的对象存储网络架构：
9.2. 常规服务安全
9.2.1. 以非 root 用户身份运行服务
建议您将 swift 配置为在非 root (UID 0)服务帐户下运行。一个建议是 director 部署的主组 的用户名 swift。对象存储服务包括： swift proxy-server、container-server、account-server。
9.2.2. 文件权限
/var/lib/config-data/puppet-generated/swift/etc/swift/ 目录包含有关环拓扑和环境配置的信息。建议使用以下权限：
chown -R root:swift /var/lib/config-data/puppet-generated/swift/etc/swift/*
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type f -exec chmod 640 {} \;
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type d -exec chmod 750 {} \;
此限制仅允许 root 修改配置文件，同时仍然允许服务读取它们，因为 swift 组中的成员资格。
9.3. 保护存储服务
以下是各种存储服务的默认侦听端口：
-
帐户服务 -
TCP/6002 -
容器服务 -
TCP/6001 -
对象服务 -
TCP/6000 -
rsync -
TCP/873
如果使用 ssync 而不是 rsync，则会使用对象服务端口来维护持久性。
在存储节点中不会发生身份验证。如果您能够连接到其中一个端口上的存储节点，您可以在无需身份验证的情况下访问或修改数据。为了帮助缓解这个问题，您应该遵循之前针对使用私有存储网络的建议。
9.3.1. 对象存储帐户术语
swift 帐户不是用户帐户或凭证。存在以下区别：
- Swift 帐户 - 容器的集合（而不是用户帐户或身份验证）。您使用的身份验证系统将决定与帐户关联的用户以及它们可以访问它的方式。
- Swift 容器 - 对象集合。容器的元数据可用于 ACL。ACL 的用法取决于所使用的身份验证系统。
- Swift 对象 - 实际数据对象。对象级别的 ACL 也与元数据一同可用，它依赖于所使用的身份验证系统。
在每个级别，您都有控制用户访问的 ACL；ACL 根据使用中的身份验证系统进行解释。最常见的身份验证提供程序类型是 Identity Service (keystone)；自定义身份验证提供程序也可用。
9.4. 保护代理服务
代理节点应至少有两个接口（物理或虚拟）：一个公共节点和一个私有接口。您可以使用防火墙或服务绑定来帮助保护公共接口。面向公众的服务是处理端点客户端请求的 HTTP Web 服务器，对其进行验证并执行适当的操作。专用接口不需要任何侦听服务，而是用于建立到专用存储网络上存储节点的出站连接。
9.4.1. HTTP 侦听端口
director 将 Web 服务配置为在非 root 用户（无 UID 0）用户下运行。使用大于 1024 的帮助的端口号可避免以 root 用户身份运行任何部分 web 容器。通常，使用 HTTP REST API （和执行自动身份验证）的客户端将从身份验证响应中检索需要的完整 REST API URL。OpenStack REST API 允许客户端验证一个 URL，然后重定向为为实际服务使用完全不同的 URL。例如，客户端可以向 https://identity.cloud.example.org:55443/v1/auth 进行身份验证并使用其身份验证密钥和存储 URL （代理节点或负载均衡器的 URL）获得响应 https://swift.cloud.example.org:44443/v1/AUTH_8980。
9.4.2. 负载均衡器
如果 的 选项无法使用 Apache，或者用于卸载 TLS 工作的性能，您可能会采用专用的网络设备负载均衡器。这是在使用多个代理节点时提供冗余和负载平衡的一种常见方法。
如果您选择卸载 TLS，请确保负载均衡器和代理节点之间的网络链接位于私有(V) LAN 网段中，以便网络中的其他节点（可能被破坏）无法有线tap (sniff)未加密流量。如果发生此类漏洞，攻击者可以访问端点客户端或云管理员凭证并访问云数据。
您使用的身份验证服务将决定您在响应端点客户端时配置不同的 URL，从而允许它们使用负载均衡器而不是单独的代理节点。
9.5. 对象存储身份验证
Object Storage (swift)使用 WSGI 模型为不能提供通用可扩展性的中间件功能提供，也可用于验证端点客户端。身份验证提供程序定义哪些角色和用户类型。有些使用传统的用户名和密码凭证，另一些则可能利用 API 密钥令牌甚至客户端 x.509 证书。自定义提供程序可以使用自定义中间件集成。
默认情况下，对象存储附带了两种身份验证中间件模块，它们分别可用作开发自定义身份验证中间件的示例代码。
9.5.1. Keystone
Keystone 是 OpenStack 中常用的身份提供程序。它还可用于对象存储中的身份验证。
9.6. 加密 at-rest swift 对象
Swift 可以与 Barbican 集成，以透明地加密和解密您的存储(at-rest)对象。at-rest 加密与 in-transit 加密不同，它引用了在存储于磁盘上时已加密的对象。
Swift 以透明方式执行这些加密任务，在上传到 swift 时自动加密对象，然后在提供给用户时自动解密。这个加密和解密使用相同的(ymmetric)密钥进行，密钥保存在 Barbican 中。
如需更多信息，请参阅 Barbican 集成指南： https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.0/html-single/manage_secrets_with_openstack_key_manager/
9.7. 其他项目
在 每个节点上的 /var/lib/config-data/puppet-generated/swift/swift.conf 中，有一个 swift_hash_path_prefix 设置和一个 swift_hash_path_suffix 设置。提供了用于减少所存储对象的哈希冲突的几率，以及一个用户覆盖另一个用户的数据。
这个值应该首先设置有加密保护随机数生成器，并在所有节点中保持一致。确保它使用正确的 ACL 保护，并且您有备份副本以避免数据丢失。
第 10 章 监控和日志记录
日志管理是监控 OpenStack 部署安全状态的重要组件。除了组成 OpenStack 部署的组件活动外，日志还能够深入了解管理员、项目和实例的 BAU 操作。
日志不仅对于主动安全性和持续合规活动提供了重要价值，还对调查和事件响应提供了宝贵的信息源。例如，分析 keystone 访问日志可能会提醒您失败登录、它们的频率、原始 IP 以及事件是否仅限于选择帐户，其他相关信息。
director 包括使用 AIDE 的入侵检测功能，以及 keystone 的 CADF 审计。如需更多信息，请参阅 director 的强化章节。
10.1. 强化监控基础架构
集中式日志记录系统是入侵者的高价值目标，因为成功破坏可能会使其在事件记录中擦除或篡改程序。建议您加深对监控平台进行强化。此外，考虑对这些系统进行定期备份，在发生停机或 DoS 时进行故障转移计划。
10.2. 要监控的事件示例
事件监控是一种更加主动的方法，可以保护环境，提供实时检测和响应。存在多个工具，可以协助监控。对于 OpenStack 部署，您需要监控硬件、OpenStack 服务和云资源的使用情况。
本节介绍了可能需要了解的一些示例事件。
此列表并非详尽。您需要考虑可能适用于特定网络的其他用例，并且您可能会考虑行为。
- 检测没有日志生成的情况是一个高值事件。这种差距可能表示服务失败，甚至是已临时关闭日志记录或修改日志级别的入侵者来隐藏其跟踪。
- 应用程序事件，如启动或停止事件，这些事件是非计划可能的影响。
- OpenStack 节点上的操作系统事件，如用户登录或重启。它们可以提供宝贵的洞察，以区分正确和系统不当的使用。
- 网络桥接将关闭。这可能是因为服务中断风险而出现的可操作事件。
- iptables 清空 Compute 节点上的事件，导致访问实例的丢失。
为了降低身份服务中用户、项目或域删除中孤立实例的安全性风险，存在讨论生成通知，并让 OpenStack 组件根据情况等情况响应这些事件，如终止实例、断开连接卷、回收 CPU 和存储资源等。
安全监控控制（如入侵检测软件、防病毒软件）和删除实用程序可生成显示何时或入侵发生的时间和攻击方式的日志。这些工具可在 OpenStack 节点上部署时提供一层保护。项目用户也可能希望在其实例上运行此类工具。
第 11 章 项目数据保密
OpenStack 的设计旨在支持具有不同数据要求的项目之间的多租户。云操作员将需要考虑其适用的数据隐私问题和法规。本章阐述了数据在 OpenStack 部署方面的存在性和争议。
11.1. 数据隐私问题
本节介绍了 OpenStack 部署中数据隐私的一些问题。
11.1.1. 数据驻留
过去几年里，数据的隐私和隔离一直是云采用的主要障碍。对于拥有云中数据的问题，云操作员最终是否可以信任此数据的 custodian 在过去存在重大问题。
某些 OpenStack 服务可以访问属于项目或引用项目信息的数据和元数据。例如，存储在 OpenStack 云中的项目数据可能包括以下项目：
- 对象存储对象.
- 计算实例临时文件系统存储.
- 计算实例内存.
- 块存储卷数据。
- 用于计算访问的公钥.
- 镜像服务中的虚拟机镜像。
- 实例快照.
- 传递给计算配置驱动器扩展的数据。
OpenStack 云存储的元数据包括以下项目（此列表不是ex-exustive）：
- 机构名称。
- 用户的"续订名称"。
- 正在运行的实例、存储桶、对象、卷和其他与配额相关的项目的数量或大小。
- 运行实例或存储数据的小时数。
- 用户的 IP 地址。
- 内部为计算镜像捆绑生成的私钥。
11.1.2. 数据处理
良好的实践建议，Operator 必须清理云系统介质（数字和非位数），然后再发布机构控制前，或发布之前必须进行重复使用。清理方法应根据特定安全域和信息敏感度实施适当的强度和完整性级别。
NIST Special Publication 800-53 Revision 4 会对这个主题进行特定视图：
The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal.
在开发通用数据处理和清理指南时，云操作员应考虑以下内容（根据 NIST 推荐的安全控制）：
- 跟踪、记录和验证介质清理和处理操作。
- 测试健全设备和流程以验证性能是否正确。
- 在将此类设备连接到云基础架构之前，可清理可移动的存储设备。
- 销毁无法清理的云系统介质。
因此，OpenStack 部署需要解决以下实践：
- 保护数据纠删代码
- 实例内存清理
- 块存储卷数据
- 计算实例临时存储
- 裸机服务器清理
11.1.3. 数据没有安全清除
在 OpenStack 中，一些数据可能会被删除，但不在上述 NIST 标准上下文中安全清除。这通常适用于数据库中存储的大部分或所有上述定义元数据和信息。这可能是使用数据库和/或系统配置修复，以实现自动清空和定期的空闲空间。
11.1.4. 实例内存清理
特定于各种虚拟机监控程序的处理是实例内存的处理。此行为在计算中没有定义，但一般情况下，管理程序通常会尽力在实例创建或同时删除实例时清理内存。
11.1.5. 加密 Cinder 卷数据
强烈建议使用 OpenStack 卷加密功能。这在卷加密下的 Data Encryption 部分中讨论。使用此功能时，通过安全地删除加密密钥来完成数据架构。在创建卷时，最终用户可以选择此功能，但请注意，管理员必须先执行一次性卷加密功能集。
如果没有使用 OpenStack 卷加密功能，则通常还难以启用其他方法。如果使用了后端插件，则可能通过独立的加密方式或非标准覆盖解决方案。OpenStack 块存储的插件将以多种方式存储数据。许多插件都特定于供应商或技术，而其他插件则是针对文件系统（比如 LVM 或 ZFS）的更多 DIY 解决方案。安全销毁数据的方法将因插件、供应商和文件系统而异。
有些后端（如 ZFS）将支持写时复制以防止数据泄露。在这种情况下，从未写入的块中读取始终会返回零。其他后端（比如 LVM）可能不会原生支持，因此 cinder 插件负责在将之前写入的块放置到用户之前覆盖它们。务必要检查确保所选卷后端提供的哪些保证，并查看哪些补救可用于这些未提供的保证。
11.1.6. 镜像服务延迟删除功能
镜像服务具有延迟删除功能，该功能将在指定的时间期限内暂停删除镜像。如果此行为是安全问题，请考虑禁用此功能；您可以编辑 glance-api.conf 文件并将 latency _delete 选项设置为 False 来实现这一点。
11.1.7. 计算软删除功能
compute 具有软删除功能，它允许在指定时间段内删除的实例处于 soft-delete 状态。此期间内可以恢复实例。要禁用 soft-delete 功能，请编辑 /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf 文件并将 reclaim_instance_interval 选项留空。
11.1.8. Compute 实例的临时存储
请注意，OpenStack 临时磁盘加密功能提供了一种方式，可以在活跃使用期间以及数据被销毁时提高临时存储隐私和隔离。如同加密块存储一样，只需删除加密密钥即可有效地销毁数据。
另一种提供数据隐私的措施（在创建后和销毁临时存储）取决于所选管理程序和计算插件。
计算的 libvirt 驱动程序可能会直接在文件系统上或 LVM 中维护临时存储。虽然当删除时文件系统存储通常不会覆盖数据，尽管有保证不会向用户置备脏扩展。
当使用基于块的 LVM 支持的临时存储时，需要计算软件安全地清除块以防止信息泄露。之前，存在与不当删除临时块存储设备有关的漏洞披露。
文件系统存储是临时块设备比 LVM 更为安全的解决方案，因为无法对用户进行脏扩展。但是，务必要注意用户数据没有被销毁，因此建议加密后备文件系统。
11.2. 裸机置备的安全强化
对于裸机置备基础架构，您应该考虑一般的安全强化基板管理控制器(BMC)和 IPMI。例如，您可以在 provisioning 网络中隔离这些系统，配置非默认密码和强大的密码，并禁用不需要的管理功能。如需更多信息，请参阅有关安全强化这些组件的厂商指导。
如果可能，请考虑把基于 Redfish 的 BMC 与旧的 BMC 进行评估。
11.2.1. 硬件身份
在部署服务器时，可能并不总是有可靠的方法将其与攻击者的服务器区分。这个功能可能依赖于硬件/BMC 延长到某种程度，但通常情况似乎没有人为服务器内置有可验证的识别方式。
11.3. 数据加密
存在用于实现者在存储于磁盘或通过网络传输时的项目数据，如下方所述的 OpenStack 卷加密功能。这高于用户在将自己的数据发送到其供应商之前对自己的数据进行加密的一般建议。
代表项目加密数据的重要性与攻击者可以访问项目数据的供应商相关风险。在政府中可能要求，以及每个策略、私有合同要求，甚至在与公共云提供商私有合同有关的法律情况下。在选择项目加密策略前，请考虑获取风险评估和法律建议。
每个实例或每个对象加密更为可取，以降序、每个项目、每个主机和每个云聚合使用。本建议消除了实施的复杂性和难度。目前，在某些项目中，即使每个项目也是如此，也无法实施加密。实施者应该考虑加密项目数据。
通常，数据加密通过丢弃密钥，对可靠销毁项目和实例数据的能力进行了积极联系。请注意，在这样做时，以可靠且安全的方式销毁这些密钥非常重要。
为用户加密数据的机会会存在：
- 对象存储对象
- 网络数据
11.3.1. 卷加密
OpenStack 中的卷加密功能支持每个项目的隐私。支持以下功能：
- 创建和使用加密卷类型，通过控制面板或命令行界面启动
- 启用加密并选择参数，如加密算法和密钥大小
- iSCSI 数据包中包含的卷数据已被加密
- 支持加密原始卷的加密备份
- 卷加密状态的仪表板表示。包括表示卷已加密，并包含加密参数，如算法和密钥大小
- 使用密钥管理服务接口
11.3.2. 对象存储对象
Object Storage (swift)支持在存储节点上静态时对象数据的可选加密。对象数据的加密旨在减少未经授权方获得对磁盘的物理访问而被读取的风险。
静态数据进行加密由中间件实施，该中间件可包含在代理服务器 WSGI 管道中。该功能是 swift 集群内部，不通过 API 公开。客户端不知道此数据由此功能内部加密到 swift 服务；内部加密的数据绝不会通过 swift API 返回到客户端。
在 swift 中的静态时，以下数据会被加密：
-
对象内容，例如对象
PUT请求正文的内容。 -
具有非零内容的对象的实体标签(
ETag)。 -
所有自定义用户对象元数据值。例如，使用带有
PUT或POST请求的X-Object-Meta-前缀的标头发送的元数据。
以上列表中不包含的任何数据或元数据没有加密，包括：
- 帐户、容器和对象名称
- 帐户和容器自定义用户元数据值
- 所有自定义用户元数据名称
- 对象 Content-Type 值
- 对象大小
- 系统元数据
11.3.3. 块存储性能和后端
在启用操作系统时，可以使用 Intel 和 AMD 处理器中当前可用的硬件加速功能来增强 OpenStack 卷加密性能。OpenStack 卷加密功能和 OpenStack 临时磁盘加密功能都使用 dm-crypt 保护卷数据。DM-crypt 是 Linux 内核版本 2.6 及之后的版本中的透明磁盘加密功能。在使用硬件加速时，两个加密功能的性能影响会被最小化。
11.3.4. 网络数据
Compute 节点的项目数据可以通过 IPsec 或其他隧道加密。这种做法在 OpenStack 中并不常见或标准，但对实施者而言是一个方便的选择。同样，加密的数据也会保持加密，因为它通过网络传输。
11.4. 密钥管理
为了解决经常提到的项目数据隐私的问题，OpenStack 社区内有显著的兴趣，使数据加密更加普遍。最终用户在保存到云之前对数据进行加密相对容易，这是用于项目对象的可行路径，如介质文件、数据库存档等。在某些实例中，客户端侧加密用于加密虚拟化技术持有的数据，这些数据需要客户端交互，如演示密钥、解密以供以后使用的数据。
Barbican 可帮助项目更加无缝地加密数据，并可访问，而无需给具有密钥管理的用户产生负担。作为 OpenStack 的一部分，提供加密和密钥管理服务可以简化数据执行的安全性，并帮助解决客户对数据的隐私或滥用的问题。
卷加密和临时磁盘加密功能依赖于密钥管理服务（如 barbican）来创建和安全强化密钥存储。
第 12 章 管理实例安全性
在虚拟化环境中运行实例的一个好处是安全性控制的新机会，这些控制在在裸机上部署时通常不可用。某些技术可应用于虚拟化堆栈，为 OpenStack 部署提供改进的信息保障。具有强安全要求的 Operator 可能需要考虑部署这些技术，但并非所有情况都适用。在某些情形中，因为预定义的业务需求，技术可能会排除在云中使用。同样，一些技术会检查实例数据，如运行状态，这些数据可能对系统的用户不可避免。
本章介绍了这些技术及其可用于帮助提高实例或底层节点的安全性的情况。可能的隐私顾虑也会突出显示，其中可能包括数据透传、内省或熵源。
12.1. 为实例提供熵
本章使用术语 熵 来引用实例可用的随机数据的质量和源。加密技术通常依赖于随机性，这需要从高质量的熵池中获取。实例通常很难获得足够的熵来支持这些操作；这称为熵。此条件可以在实例中清单，就像看似不相关。例如：实例等待 SSH 密钥生成速度可能会导致启动时间较慢。这种状况还可能导致用户从实例内部使用不佳的、高质量的熵源，从而使应用程序在云中运行不太安全。
幸运的是，您可以通过为实例提供高质量的熵源来解决这些问题。这可以通过在云中有足够的硬件随机数生成器(HRNG)来支持实例来实现。在这种情况下，足够一些特定于域。对于日常操作，现代 HRNG 可能生成足够的熵来支持 50-100 计算节点。高带宽 HRNG，比如 Intel Ivy Bridge 和较新的处理器可用的 RdRand 指令可能会处理更多节点。对于给定的云，架构师需要了解应用程序要求，以确保有足够的熵。
Virtio RNG 是一个随机数字生成器，它默认使用 /dev/random 作为熵源。它还可以配置为使用硬件 RNG，或者一个工具，如熵收集守护进程(EGD)，通过部署提供相当地分发熵的方法。您可以使用 hw_rng 元数据属性在实例创建时启用 Virtio RNG。
12.2. 将实例调度到节点
在创建实例之前，必须选择用于镜像实例化的主机。此选择由 nova-scheduler 执行，它决定了如何分配计算和卷请求。
FilterScheduler 是计算的默认调度程序，但存在其他调度程序。该功能适用于与 过滤器提示 协作，以确定应启动实例的位置。通过这种主机选择的过程，管理员可以满足许多不同的安全性和合规性要求。如果数据隔离是主要关注点，您可以选择让项目实例尽可能驻留在同一主机上。相反，出于可用性或容错的原因，您可以尝试让实例驻留在很多不同的主机上。
过滤器调度程序位于以下主要类别下：
- 基于资源的过滤器 - 根据虚拟机监控程序主机集的系统资源使用情况来确定实例放置，并可在空闲或已用的属性（如 RAM、IO 或 CPU 使用率）上触发。
- 基于镜像的过滤器 - 根据所使用的镜像元数据（如虚拟机操作系统或所用镜像类型）创建实例创建。
- 基于环境的过滤器 - 根据外部详细信息（如在一个特定 IP 范围内、跨可用性区域）或与其他实例在同一主机上确定实例放置。
- 自定义标准 - 根据用户或管理员提供的标准（如信任或元数据解析）来分离实例创建。
可以一次性应用多个过滤器。例如，serverGroupAffinity 过滤器检查某个实例是否在特定一组主机的成员上创建，而 ServerGroupAntiAffinity 过滤器会检查同一实例不在另一特定主机组上创建。请注意，这两个过滤器通常同时启用，永远不会相互冲突，因为它们每次检查给定属性值时不得相互冲突，且不能同时是 true。
DiskFilter 过滤器能够超订阅磁盘空间。虽然通常不是问题，但这可能会对精简配置的存储设备有问题。此过滤器应当与应用良好测试的配额一起使用。此功能已被弃用，在 Red Hat OpenStack Platform 12 后不应使用。
考虑禁用过滤器，用于解析用户提供的对象，或者可以操作（如元数据）。
12.3. 使用可信镜像
在云环境中，用户使用预安装的镜像或他们自己上传的镜像。在这两种情况下，用户应该能够确保其使用的镜像没有被篡改。验证镜像是安全的基础。需要来自镜像源到使用其目标的信任链。这可以通过签名从可信源获取的镜像，并在使用前验证签名来完成。下面将讨论获取和创建经验证镜像的各种方法，并介绍了镜像签名验证功能的描述。
12.3.1. 创建镜像
OpenStack 文档提供如何创建和上传镜像上传到镜像服务的指导。另外，假设您有一个安装和增强客户机操作系统的过程。以下项目将提供将您的镜像传送到 OpenStack 的其他指导。获取镜像的各种选项。每种步骤均有可帮助验证镜像成熟的特定步骤。
- 选项 1： 包含来自可信源的引导介质.例如，您可以从官方红帽源下载镜像，然后执行额外的 checksum 验证。
- 选项 2： 使用 OpenStack 虚拟机镜像指南。在这种情况下，您需要遵循您的机构操作系统强化指南。
-
选项 3： 使用自动镜像构建器。以下示例使用 Oz 镜像构建器：OpenStack 社区最近创建了名为
disk-image-builder的较新的工具，它还没有进行安全评估。
在这个示例中，RHEL 6 CCE-26976-1 帮助 Oz 在 Oz 内实施 NIST 800-53 第 AC-19 (d)。
<template> <name>centos64</name> <os> <name>RHEL-6</name> <version>4</version> <arch>x86_64</arch> <install type='iso'> <iso>http://trusted_local_iso_mirror/isos/x86_64/RHEL-6.4-x86_64-bin-DVD1.iso</iso> </install> <rootpw>CHANGE THIS TO YOUR ROOT PASSWORD</rootpw> </os> <description>RHEL 6.4 x86_64</description> <repositories> <repository name='epel-6'> <url>http://download.fedoraproject.org/pub/epel/6/$basearch</url> <signed>no</signed> </repository> </repositories> <packages> <package name='epel-release'/> <package name='cloud-utils'/> <package name='cloud-init'/> </packages> <commands> <command name='update'> yum update yum clean all sed -i '/^HWADDR/d' /etc/sysconfig/network-scripts/ifcfg-eth0 echo -n > /etc/udev/rules.d/70-persistent-net.rules echo -n > /lib/udev/rules.d/75-persistent-net-generator.rules chkconfig --level 0123456 autofs off service autofs stop </command> </commands> </template>
考虑避免手动镜像构建过程，因为它比较复杂且容易出错。另外，使用自动化系统（如 Oz）进行镜像构建，或者一个配置管理实用程序（如 Chef 或 Puppet）进行引导镜像强化，使您能够在一段时间内生成一致的镜像，并跟踪其相应强化准则。
如果订阅公共云服务，您应该检查云提供商中用于生成默认镜像的流程的概述。如果该供应商允许您上传自己的镜像，您可能希望确保在使用镜像来创建实例之前验证您的镜像是否没有被修改。要做到这一点，请参阅 _ verify image signatures_ 或以下段落（如果没有使用签名）。
Image Service (glance)用于将镜像上传到节点上的 Compute 服务。此传输应通过 TLS 进行进一步强化。镜像位于节点上后，它会使用基本校验和进行检查，然后根据要启动的实例的大小扩展其磁盘。如果稍后，会在这个节点上使用相同的实例大小启动同一镜像，它会从同一扩展的镜像启动。由于此扩展的镜像在启动前不会默认重新验证，因此存在其被篡改的风险。除非手动检查文件在生成的镜像中，否则用户不会感知感知。为了帮助缓解这个问题，请参阅验证镜像签名主题部分。
12.3.2. 验证镜像签名
OpenStack 中现在提供了与镜像签名相关的某些功能。从 Red Hat OpenStack Platform 13 开始，镜像服务可以验证这些已签名的镜像，并提供完整信任链，计算服务可以选择在镜像引导前执行镜像签名验证。在镜像引导前成功验证签名可确保签名镜像没有更改。启用此功能后，可以检测未经授权地修改镜像（例如，修改镜像使其包含恶意软件或 rootkits）。
您可以通过在 /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova_libvirt/etc/nova/nova.conf 文件中将 标志设置为 verify_ glance_signaturesTrue 来启用实例签名验证。启用后，计算服务在从 glance 检索时会自动验证已签名的实例。如果这个验证失败，引导过程将无法启动。
启用这个功能后，没有签名（未签名镜像）的镜像也会失败验证，引导过程也不会启动。
12.4. 迁移实例
OpenStack 和底层虚拟化层为在 OpenStack 节点之间实时迁移镜像提供，允许您在无实例停机的情况下无缝地滚动升级 Compute 节点。但是，实时迁移也存在重大风险。要了解相关风险，以下是实时迁移期间执行的高级步骤：
- 启动目标主机上的实例
- 传输内存
- 停止客户机和同步磁盘
- 传输状态
- 启动客户端
某些操作（如冷迁移、调整大小和 shelve）都可能会导致实例的数据通过网络传输给其他服务，等等。
12.4.1. 实时迁移风险
在实时迁移过程的不同阶段，实例运行时内存和磁盘的内容以纯文本形式通过网络传输。因此，在使用实时迁移时，需要解决多个风险。以下非行为列表详细描述了其中一些风险：
- 拒绝服务(DoS)：如果迁移过程中出现某种失败，实例可能会丢失。
- 数据暴露：必须安全地处理内存或磁盘传输。
- 数据操作：如果内存或磁盘传输没有被安全处理，则攻击者可以在迁移过程中操作用户数据。
- 代码注入：如果内存或磁盘传输没有被安全处理，那么攻击者可以在磁盘或内存中操作可执行文件，可以在迁移期间在磁盘或内存中操作。
12.4.2. 实时迁移缓解方案
可以通过多种方式来帮助缓解与实时迁移相关的一些风险。下面介绍了这些部分：
12.4.2.1. 禁用实时迁移
目前，OpenStack 中默认启用实时迁移。默认情况下，实时迁移是仅管理员的任务，因此用户无法启动此操作，只有管理员（值得信任）。通过在 nova policy.json 文件中添加以下几行可以禁用实时迁移：
"compute_extension:admin_actions:migrate": "!", "compute_extension:admin_actions:migrateLive": "!",
另外，当通过 49261 阻止 TCP 端口 49152 时，实时迁移可能会失败，或者确保 nova 用户在计算主机之间没有免密码 SSH 访问。
请注意，实时迁移的 SSH 配置会显著降低：新用户已创建(nova_migration)，并将 SSH 密钥限制为该用户，且仅在白名单的网络中使用。然后，打包程序脚本会限制可以运行的命令（例如，libvirt 套接字上的 netcat）。
12.4.2.2. 迁移网络
实时迁移流量以纯文本形式传输正在运行的实例的磁盘和内存，目前默认托管在内部 API 网络中。
12.4.2.3. 加密的实时迁移
如果有足够的要求（如升级）使实时迁移保持启用，那么 libvirtd 可以为实时迁移提供加密的隧道。但是，这个功能不会在 OpenStack Dashboard 或 nova-client 命令中公开，只能通过 libvirtd 的手动配置来访问。然后，实时迁移过程会更改为以下高级别步骤：
- 实例数据从虚拟机监控程序复制到 libvirtd。
- 在源和目标主机上的 libvirtd 进程之间创建一个加密的隧道。
- 目标 libvirtd 主机将实例重新复制到底层虚拟机监控程序。
对于 Red Hat OpenStack Platform 13，建议的方法是使用隧道迁移，这在将 Ceph 用作后端时默认启用。如需更多信息，请参阅 https://docs.openstack.org/nova/queens/configuration/config.html#libvirt.live_migration_tunnelled。
12.5. 监控、警报和报告
实例是可以在主机之间复制的服务器镜像。因此，最好在物理和虚拟主机之间应用日志。应记录操作系统和应用程序事件，包括访问主机和数据的事件、用户添加和删除、特权更改，等等。考虑将结果导出到日志聚合器，用于收集日志事件，以便分析它们，并将它们存储以供参考或进一步操作。一个常见的工具是 ELK 堆栈或 Elasticsearch、Logstash 和 Kibana。
这些日志应定期检查，甚至在网络操作中心(NOC)执行的实时视图中监控。
您需要进一步确定哪些事件将触发随后发送到响应者采取行动的警报。
如需更多信息，请参阅 监控工具配置指南
12.5.1. 更新和补丁
管理程序运行独立的虚拟机。此管理程序可以在操作系统中或直接在硬件上运行（称为裸机）。对虚拟机监控程序的更新不会传播到虚拟机。例如，如果部署正在使用 KVM 且有一组 CentOS 虚拟机，则对 KVM 的更新不会更新 CentOS 虚拟机上运行的任何内容。
考虑将虚拟机明确的所有权分配给所有者，然后负责虚拟机的强化、部署和持续功能。您还应该计划定期部署更新，同时首次在类似于生产的环境中进行测试。
12.5.2. 防火墙和实例配置集
最常见的操作系统包括基于主机的防火墙，用于额外的安全层。实例应尽可能运行尽可能少的应用（如果可能），实例上运行的所有应用程序都应进行性能分析，以确定应用程序需要访问哪些系统资源、运行所需的最低特权级别，以及将进入和来自于虚拟机的预期网络流量。此预期的流量应当作为允许的流量（或列入）添加到基于主机的防火墙中，以及任何必要的日志记录和管理通信，如 SSH 或 RDP。防火墙配置中应明确拒绝所有其他流量。
在 Linux 实例上，上面的应用配置文件可与 audit2 allow 等工具结合使用，从而构建 SELinux 策略，进一步保护大多数 Linux 分发的敏感信息。SELinux 使用用户、策略和安全上下文的组合来划分应用程序运行所需的资源，并从不需要的其他系统资源进行分段。
Red Hat OpenStack Platform 默认启用了 SELinux，策略是为 OpenStack 服务自定义的策略。根据需要，定期查看这些策略。
12.5.2.1. 安全组
OpenStack 为主机和网络提供安全组，为给定项目中的实例添加防御能力。它们与基于主机的防火墙类似，因为它们根据端口、协议和地址允许或拒绝传入的流量。但是，安全组规则仅应用于传入流量，而基于主机的防火墙规则可以应用到传入和传出流量。主机和网络安全组规则也可以有冲突和拒绝合法流量。考虑检查是否正确为所使用的网络配置了安全组。如需了解更多详细信息，请参阅本指南中的安全组。
您应该启用安全组和端口安全性，除非您特别需要禁用它们。要基于防御方法构建，建议您将粒度规则应用到实例。
12.5.3. 访问实例控制台
默认情况下，可以通过虚拟控制台远程访问实例的控制台。这对于故障排除非常有用。Red Hat OpenStack Platform 使用 VNC 进行远程控制台访问。
-
考虑使用防火墙规则锁定 VNC 端口。默认情况下，
nova_vnc_proxy使用6080和13080。 -
确认 VNC 流量由 TLS 加密。对于基于 director 的部署，请从
UseTLSTransportForVnc开始。
12.5.4. 证书注入
如果您需要通过 SSH 连接到您的实例，可以配置 Compute，以便在创建时自动将所需的 SSH 密钥注入到实例中。
第 13 章 消息排队
消息排队服务有助于促进 OpenStack 中的进程间通信。这可以通过以下消息排队服务后端完成：
- RabbitMQ - Red Hat OpenStack Platform 默认使用 RabbitMQ。
- Qpid
RabbitMQ 和 Qpid 都是高级消息队列协议(AMQP)框架，它为同行通信提供消息队列。队列实现通常部署为集中式或分散队列服务器池。
消息队列有效促进了跨 OpenStack 部署的命令和控制功能。允许对队列的访问后，便不会再执行其他授权检查。通过队列访问的服务会验证实际消息有效负载中的上下文和令牌。但是，您必须记下令牌的过期日期，因为令牌可能会可重复使用，并可在基础架构中授权其他服务。
OpenStack 不支持消息级信任，如消息签名。因此，您必须保护并验证消息传输本身。对于高可用性(HA)配置，您必须执行 queue-to-queue 身份验证和加密。
13.1. 消息传递安全性
本节讨论 OpenStack 中使用的三种最常见的消息排队解决方案的安全强化方法：RabbitMQ 和 Qpid。
13.2. 消息传递传输安全性
基于 AMQP 的解决方案(Qpid 和 RabbitMQ)支持使用 TLS 的传输级安全性。
考虑为您的消息队列启用传输层安全性加密。使用 TLS 进行消息传递客户端连接，提供从篡改和拖放到消息传递服务器的通信保护。以下是如何为两个常见消息传递服务器配置 TLS 的指南： Qpid 和 RabbitMQ。当您配置消息传递服务器用来验证客户端连接的可信证书颁发机构(CA)捆绑包时，建议只限制用于节点的 CA，最好是内部管理的 CA。可信 CA 的捆绑包将决定哪些客户端证书将获得授权并传递设置 TLS 连接的客户端-服务器验证步骤。
安装证书和密钥文件时，请确保对文件权限进行限制，例如使用 chmod 0600，并且所有权仅限于消息传递服务器守护进程用户，以防止消息传递服务器上的其他进程和用户进行未经授权的访问。
13.2.1. RabbitMQ 服务器 SSL 配置
以下几行应添加到系统范围的 RabbitMQ 配置文件中，通常为 /etc/rabbitmq/rabbitmq.config ：
[
{rabbit, [
{tcp_listeners, [] },
{ssl_listeners, [{"<IP address or hostname of management network interface>", 5671}] },
{ssl_options, [{cacertfile,"/etc/ssl/cacert.pem"},
{certfile,"/etc/ssl/rabbit-server-cert.pem"},
{keyfile,"/etc/ssl/rabbit-server-key.pem"},
{verify,verify_peer},
{fail_if_no_peer_cert,true}]}
]}
].
tcp_listeners 选项被设置为 []，以防止它监听非 SSL 端口。ssl_listeners 选项应限制为仅侦听服务的管理网络。
13.3. 队列身份验证和访问控制
RabbitMQ 和 Qpid 为控制对队列的访问提供了身份验证和访问控制机制。
简单身份验证和安全层(SASL)是 Internet 协议中身份验证和数据安全性的框架。RabbitMQ 和 Qpid 均提供 SASL 以及除简单用户名和密码之外的其他可插入验证机制，从而增强身份验证安全性。虽然 RabbitMQ 支持 SASL，但 OpenStack 目前不允许请求特定的 SASL 身份验证机制。OpenStack 中的 RabbitMQ 支持通过未加密的连接或用户名以及 X.509 客户端证书进行用户名和密码的身份验证，从而建立安全的 TLS 连接。
考虑在所有 OpenStack 服务节点上配置 X.509 客户端证书，以便客户端连接消息传递队列，并在可能的情况下使用 X.509 客户端证书执行身份验证。在使用用户名和密码时，应为每个服务和节点创建帐户，以便精细的可审核访问队列。
在部署前，请考虑排队服务器使用的 TLS 库。Qpid 使用 Mozilla 的 NSS 库，而 RabbitMQ 使用 Erlang 的 TLS 模块，它们使用 OpenSSL。
13.3.1. RabbitMQ 的 OpenStack 服务配置
本节介绍了 OpenStack 服务的典型 RabbitMQ 配置：
[DEFAULT] rpc_backend = nova.openstack.common.rpc.impl_kombu rabbit_use_ssl = True rabbit_host = RABBIT_HOST rabbit_port = 5671 rabbit_user = compute01 rabbit_password = RABBIT_PASS kombu_ssl_keyfile = /etc/ssl/node-key.pem kombu_ssl_certfile = /etc/ssl/node-cert.pem kombu_ssl_ca_certs = /etc/ssl/cacert.pem
将 RABBIT_PASS 替换为适当的密码。
13.3.2. Qpid 的 OpenStack 服务配置
本节介绍 OpenStack 服务的典型 Qpid 配置：
[DEFAULT] rpc_backend = nova.openstack.common.rpc.impl_qpid qpid_protocol = ssl qpid_hostname = <IP or hostname of management network interface of messaging server> qpid_port = 5671 qpid_username = compute01 qpid_password = QPID_PASS
用合适的密码替换 QPID_PASS。
（可选）如果将 SASL 与 Qpid 一起使用，则通过添加以下内容来指定使用的 SASL 机制：
qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>
13.4. 消息队列进程隔离和策略
每个项目都提供了多个服务来发送和接收信息。每个发送消息的二进制值都应在队列中仅回复时使用消息。
消息队列服务进程应该相互隔离，以及计算机上的其他进程。
13.4.1. 命名空间
Neutron 和 Open vSwitch (OVS)网络在命名空间内运行，但某些 OVS 主机服务没有，包括 vswitchd、libvirtd 和 QEMU。当运行容器化 control plane 时，所有 control plane 服务都会默认在网络命名空间中运行。对于在计算系统管理程序上运行的所有服务，强烈建议使用网络命名空间（因为它们运行 AMQP 服务）。这种方法可帮助防止桥接实例和管理网络之间的网络流量。
第 14 章 强化 API 端点
与 OpenStack 云交互的过程首先查询 API 端点。虽然公共和私有端点存在不同的挑战，但这些价值资产可能会带来很大的风险。
本章推荐对面向公共和面向私有的 API 端点进行安全增强。
14.1. API 端点配置建议
本节介绍了强化 API 端点的建议。
14.1.1. 内部 API 通信
OpenStack 同时提供面向公共、内部管理员和专用 API 端点。默认情况下，OpenStack 组件使用公共定义的端点。建议将这些组件配置为使用正确安全域中的 API 端点。内部管理端点允许进一步提升对 keystone 的访问，因此可能需要进一步隔离它。
服务根据 OpenStack 服务目录选择其对应的 API 端点。这些服务可能无法遵循列出的公共或内部 API 端点值。这可能会导致内部管理流量路由到外部 API 端点。
14.1.2. 在身份服务目录中配置内部 URL
身份服务目录应该了解内部 URL。虽然此功能默认为不使用，但可以通过配置来提供。另外，当此行为成为默认值后，它应该与预期更改兼容。
考虑将配置的端点与网络级别隔离开来，因为它们具有不同的访问级别。Admin 端点供云管理员访问，因为它提供了对内部或公共端点上不可用的 keystone 操作的升级访问。内部端点设计为用于将内部用于云（如由 OpenStack 服务），通常无法通过部署网络外部访问。公共端点应该为 TLS，并且部署外的唯一 API 端点可供云用户操作。
端点的内部 URL 注册由 director 自动化。如需更多信息，请参阅 https://github.com/openstack/tripleo-heat-templates/blob/a7857d6dfcc875eb2bc611dd9334104c18fe8ac6/network/endpoints/build_endpoint_map.py。
14.1.3. 为内部 URL 配置应用程序
您可以强制某些服务使用特定的 API 端点。因此，建议任何联系另一个服务的 OpenStack 服务都被明确配置，以访问正确的内部 API 端点。
每个项目可能具有定义目标 API 端点的不一致方式。未来版本的 OpenStack 寻求通过一致性地使用身份服务目录来解决这些不一致的问题。
14.1.4. 粘贴和中间件
OpenStack 中的大多数 API 端点和其他 HTTP 服务都使用 Python Paste Deploy 库。从安全角度而言，这个库通过应用程序的配置启用请求过滤管道的操作。此链中的每个元素都称为中间件。更改管道中过滤器的顺序，或者添加额外的中间件可能对不可预测的安全影响。
通常，实施者添加中间件来扩展 OpenStack 的基础功能。在 HTTP 请求管道中添加非标准软件组件时，请考虑谨慎考虑潜在的风险。
14.1.5. API 端点进程隔离和策略
您应该隔离 API 端点进程，特别是位于公共安全域中的 API 端点进程应该尽可能隔离。在部署允许的情况下，API 端点应该部署到单独的主机上，以增加隔离功能。
14.1.6. 命名空间
Linux 使用命名空间将进程分配给独立的域。本指南的其他部分将更详细地阐述系统划分。
14.1.7. 网络策略
API 端点通常会跨越多个安全区，因此您必须特别注意 API 进程分离。例如，在网络设计级别，您可以考虑仅限制对指定系统的访问。如需更多信息，请参阅有关安全区的指导。
通过仔细建模，您可以使用网络 ACL 和 IDS 技术来强制执行网络服务之间的明确点对点的通信。作为关键跨域服务，这种明确的执行适用于 OpenStack 的消息队列服务。
要强制实施策略，您可以配置服务、基于主机的防火墙（如 iptables）、本地策略(SELinux)和可选的全局网络策略。
14.1.8. 强制访问控制
您应该将 API 端点进程与计算机上的其他进程相互隔离。这些进程的配置应受 Discretionary 访问控制(DAC)和强制访问控制(MAC)的限制。这些增强型访问控制的目标是帮助对 API 端点安全漏洞的包含性。
14.1.9. API 端点速率限制
速率限制是一种控制网络基于网络应用程序接收的事件的频率。如果不存在强大的速率限制，则应用程序可能会受到各种拒绝服务攻击的影响。对 API 来说尤其如此，其特性旨在接受类似请求类型和操作的高频率。
建议所有端点（特别是公共）都提供额外的保护层，例如使用物理网络设计、速率限制代理或 Web 应用程序防火墙。
在配置和实施任何速率限制功能时，操作器会仔细规划并考虑其 OpenStack 云内用户和服务的性能需求。
请注意，对于 Red Hat OpenStack Platform 部署，所有服务都放置在负载均衡代理后面。
