默认情况下，Red Hat OpenStack Platform (RHOSP) director 使用以下工具和访问控制来创建 overcloud，以提高安全性：

您可以根据机构的需要和信任级别使用以下额外安全功能配置 director：

安全区是共享常见安全问题的通用资源、应用程序、网络和服务器。安全区应共享相同的身份验证和授权要求和用户。

您可能需要重新定义您自己的安全区，以根据云的唯一架构、环境中可接受的信任级别以及标准化要求来更精细。区域及其信任要求可能会因云实例是公共、私有还是混合而有所不同。

部署安全强化型 OpenStack 云（从至少到最受信任）所需的最小区如下：

遍历此区域的任何具有保密性或完整性要求的数据都应使用编译控制进行保护。

如果您是私有云提供商，如果实施控制以模拟实例和相关项目，则可将其视为内部和可信网络，以包括底层硬件和物理网络。

在此网络中传输的数据需要高级别的完整性和机密性。也可能具有强大的可用性要求。

除复制要求外，请勿使此网络可从云外部访问，但存储设备组件以外的存储设备从安全角度来说是敏感的。

管理网络用于系统管理、监控或备份。不要托管此区域上的 OpenStack API 或控制接口。

必须仔细配置跨多个安全区（具有不同信任级别或身份验证要求）的组件。这些连接通常是网络架构的弱点，并且应始终配置为满足所连接任何区域的最高信任级别。在很多情况下，安全控制连接的区应该是主要问题，因为攻击的可能性较高。区域满足点显示额外的攻击服务，并为攻击者将其攻击迁移到部署更敏感的部分的机会。

在某些情况下，OpenStack 操作器可能希望考虑确保集成点比它所在的任何区域更高的标准。根据上面的 API 端点示例，如果这些区域没有完全隔离，则可能会对公共 API 端点为目标。

OpenStack 的设计使得安全区分离比较困难。由于核心服务通常至少跨越两个区域，因此在将安全控制应用到它们时，必须考虑特殊考虑。

大多数类型的云部署、公共、私有或混合都暴露于某种形式的攻击。本节对攻击者进行分类，并总结了每个安全区中潜在的攻击类型。

支配整个红帽解决方案堆栈是安全的软件供应链。红帽安全战略的基石是，这种战略性重要的做法和程序集合的目标是提供具有安全内置前期和长期支持的解决方案。红帽采取的具体步骤包括：

此外，红帽还维护了一个专门的安全团队，针对我们的产品分析威胁和漏洞，并通过客户门户网站提供相关建议和更新。这个团队决定哪些问题很重要，而不是与大多数理论问题相关的问题。红帽产品安全团队在维护了专业技术方面，并对与订阅产品关联的上游社区做出了大量贡献。红帽安全公告 （红帽安全公告）的一个主要部分提供了影响红帽解决方案的安全缺陷通知 - 通常会在漏洞首次发布之日提供相关的补丁程序。

记录环境中使用的角色。通常组成 OpenStack 安装的两种定义型节点类型是：

没有编写文档严格的合规要求的云可能会受益于配置管理数据库(CMDB)。CMDB 通常用于硬件资产跟踪和整个生命周期管理。通过使用 CMDB，组织可以快速识别云基础架构硬件，如计算节点、存储节点或网络设备。CMDB 可以协助识别网络中存在的资产，这些资产可能因为维护不足、不足保护或被取代和忘记而存在漏洞。如果底层硬件支持必要的自动发现功能，OpenStack 调配系统可以提供一些基本的 CMDB 功能。

与硬件一样，应该记录 OpenStack 部署中的所有软件组件。示例包括：

有些情况下，需要确保 OpenStack 部署中网络流量的机密性或完整性。您通常会使用加密措施（如 TLS 协议）进行配置。在典型的部署中，通过公共网络传输的所有流量都应安全强化，但安全的良好做法预期内部流量也必须得到保护。不足以保护安全区分离。如果攻击者获得对 hypervisor 或主机资源的访问权限，破坏 API 端点或任何其他服务，则他们不能轻松地注入或捕获消息、命令或其他影响云的管理功能。

您应该安全强化所有带有 TLS 的区域，包括管理区服务和服务内通信。TLS 提供了相应的机制，可确保用户与 OpenStack 服务通信以及 OpenStack 服务本身之间的用户身份验证、非回复、机密性和完整性。

由于安全套接字层(SSL)协议中公布的漏洞，请考虑在首选使用 TLS 1.2 或更高版本，并且所有情况下都禁用了 SSL，除非您需要与过时的浏览器或库兼容。

公钥基础架构(PKI)是一种框架，用于提供加密算法、密码模式和协议来保护数据和身份验证。它由一组系统和流程组成，以确保可以加密流量，同时验证各方的身份。此处描述的 PKI 配置集是 PKIX 工作组开发的互联网工程任务组(IETF)公共密钥基础架构(PKIX)配置文件。PKI 的核心组件是：

许多组织拥有拥有自己的认证认证机构(CA)、证书策略和管理，它们用于为内部 OpenStack 用户或服务发布证书。公共安全区是面向互联网的组织还需要被广泛认可的公共 CA 签名的证书。对于管理网络的加密通信，建议不使用公共 CA。相反，建议大多数部署都部署自己的内部 CA。

建议 OpenStack 云架构考虑将独立的 PKI 部署用于内部系统和面向客户的服务。这允许云部署器维护对 PKI 基础架构的控制，并使内部系统请求、签名和部署证书变得更加容易。高级配置可能会将独立的 PKI 部署用于不同的安全区。这使得 OpenStack 操作器能够维护环境的加密分离，确保签发的证书不能被另一个环境识别。

用于在面向互联网的云端点（或客户不应安装标准操作系统提供证书捆绑包外）上支持 TLS 的证书应使用安装在操作系统证书捆绑包中的证书颁发机构进行置备。

默认情况下，overcloud 使用未加密的端点作为其服务。这意味着 overcloud 配置需要额外的环境文件，才能为其公共 API 端点启用 SSL/TLS。高级 Overcloud 自定义指南 描述了如何配置 SSL/TLS 证书，并将其作为 overcloud 创建过程的一部分包括 ：https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html/advanced_overcloud_customization/sect-enabling_ssltls_on_the_overcloud

OpenStack 生态系统中的某些组件、服务和应用程序可以配置为使用 TLS 库。OpenStack 中的 TLS 和 HTTP 服务通常使用 OpenSSL 实施，后者具有一个经过 FIPS 140-2 验证的模块。但是，请考虑每个应用程序或服务仍可能会在使用 OpenSSL 库时引入弱点。

对于 Red Hat OpenStack Platform 13 部署，HAProxy 不接受 TLS 1.0 连接，该连接处理 TLS 启用 API 的 TLS 连接。这通过 no-tlsv10 选项实现。对于启用了 InternalTLS 的 HA 部署，控制器平面上的跨节点流量也会加密。这包括 RabbitMQ、MariaDB 和 Redis 等等。MariaDB 和 Redis 已被弃用 TLS1.0，对 RabbitMQ 的相同弃用应该被上游向后移植。

$ ./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

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.2。其他版本（如 TLS 1.0 和 1.1）容易受到多个攻击的影响，被许多政府机构和管制的行业禁止。在您的环境中应禁用 TLS 1.0。TLS 1.1 可能用于广泛的客户端兼容性，但在启用此协议时谨慎操作。只有在存在强制兼容性要求时才启用 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 端点是向公共网络上的最终用户和管理网络上的其他 OpenStack 服务提供 API 的 HTTP 服务。目前，您可以使用 TLS 加密外部请求。要在 Red Hat OpenStack Platform 中配置，您可以在 HAproxy 之后部署 API 服务，该服务能够建立和终止 TLS 会话。

如果软件终止无法提供性能不足，硬件加速器可能会成为替代选项。这种方法需要在平台上进行额外的配置，而并非所有硬件负载均衡器都可能与 Red Hat OpenStack Platform 兼容。务必要注意任何所选 TLS 代理处理的请求大小。

为完美转发保密配置 TLS 服务器需要仔细规划密钥大小、会话 ID 和会话票据。此外，对于多服务器部署，共享状态也是重要的考虑因素。实际部署可能会考虑启用此功能来提高性能。这可以以安全加固的方式完成，但需要特别考虑关键管理。此类配置超出了本指南的范围。

OpenStack Key Manager (barbican)是 Red Hat OpenStack Platform 的机密管理器。您可以使用 barbican API 和命令行来集中管理 OpenStack 服务使用的证书、密钥和密码。barbican 目前支持以下用例：

在本发行版本中，barbican 提供与 cinder、swift、Octavia 和 Compute (nova)组件的集成。例如，您可以为以下用例使用 barbican：

如需更多信息，请参阅 Barbican 指南： https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html-single/manage_secrets_with_openstack_key_manager/

身份验证是任何现实世界 OpenStack 部署不可或缺的一部分。请仔细考虑该系统设计的这一方面。本主题的完整处理超出了本指南的范围，但以下部分将介绍一些关键主题。

在大多数情况下，身份验证是确认身份的过程，即用户实际声明的身份。熟悉的示例是在登录系统时提供用户名和密码。

OpenStack Identity service (keystone)支持多种身份验证方法，包括用户名和密码、LDAP 和其他外部身份验证方法。身份验证成功后，身份服务为用户提供了用于后续服务请求的身份验证令牌。

传输层安全性(TLS)使用 X.509 证书在服务和个人之间提供身份验证。虽然 TLS 的默认模式仅是服务器端的身份验证，但您应该考虑使用证书进行客户端身份验证，因为它在美国政府标准中强制使用。

Identity Service (keystone)可以在重复失败的登录尝试后限制对帐户的访问。重复登录尝试的模式通常是对暴力攻击的指示。这种类型的攻击在公共云部署中更为普遍。您还可以使用在配置次数失败的登录尝试后阻止帐户的外部身份验证系统缓解这个问题。然后，帐户只能通过进一步的管理干预解锁。

检测技术也可用于缓解损坏。检测涉及频繁检查访问控制日志，以识别未经授权的访问帐户尝试。可能的补救包括查看用户密码的强度，或通过防火墙规则阻止攻击的网络源。您可以在 keystone 服务器中添加限制连接数量的防火墙规则；这有助于降低攻击的有效性。

此外，检查帐户活动对于不常见的登录时间和可疑操作（如禁用帐户）非常有用。

身份服务支持组和角色的概念。用户在组拥有角色列表时从属于组。OpenStack 服务引用尝试访问该服务的用户的角色。OpenStack 策略强制器中间件考虑与每个资源关联的策略规则，然后考虑用户的 group/roles 和关联，以确定是否允许访问所请求的资源。

在配置角色、组和用户之前，您应该记录您所需的 OpenStack 安装访问控制策略。该策略应与组织的任何法规或法律要求保持一致。将来的对访问控制配置的修改应当与正式策略一致。该策略应包括用于创建、删除、禁用和启用帐户以及为帐户分配特权的条件和流程。定期检查策略，并确保配置符合批准的策略。

云管理员必须定义具有每个服务 admin 角色的用户。此服务帐户提供相应的服务来验证用户。

计算和对象存储服务可以配置为使用身份服务来存储身份验证信息。身份服务支持 TLS 的客户端身份验证，可能启用。TLS 客户端身份验证除了提供用户标识的可靠性外，还提供额外的身份验证因素。当用户名和密码被泄露时，它会降低未授权访问的风险。但是，对于每次部署都可能无法正常工作的用户，还有额外的管理开销和成本来为用户发布证书。

云管理员应保护敏感配置文件不受未授权的修改。这可以使用强制访问控制框架（如 SELinux）进行配置，包括 /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 文件和 X.509 证书。

使用 TLS 的客户端身份验证需要向服务发布证书。这些证书可以由外部或内部证书颁发机构进行签名。OpenStack 服务默认检查对可信 CA 的证书签名请求的有效性，如果签名无效或者 CA 不可信，连接将失败。云部署器可能会使用自签名证书；在这种情况下，必须禁用有效检查，或者证书应标记为可信。要禁用自签名证书验证，请在 /etc/nova/api.paste.ini 文件的 [filter:authtoken] 部分中设置 insecure=False。此设置还禁用其他组件的证书。请注意，对于容器化服务，确切的文件路径可能有所不同。

用户通过身份验证后，会生成一个令牌，以便授权和访问 OpenStack 环境。令牌可以具有变量生命周期，但到期的默认值是一小时。推荐的到期值应设置为较低的值，允许有足够的时间让内部服务完成任务。如果令牌在任务完成前过期，云可能会变得无响应或停止提供服务。计算服务使用期间的加快时间示例将是将磁盘镜像传输到 hypervisor 以便进行本地缓存所需的时间。

令牌通常在身份服务响应的更大上下文结构中传递。这些响应也提供各种 OpenStack 服务目录。每一服务均列出其名称、内部访问端点、管理和公共访问。身份服务支持令牌撤销。此清单作为 API 撤销令牌，列出已撤销的令牌和单独的 OpenStack 服务，以便缓存令牌来查询已撤销的令牌，并将它们从缓存中移除，并将相同的功能附加到已缓存的已撤销令牌列表中。Fernet 令牌是 Red Hat OpenStack Platform 13 中唯一支持的令牌。

Keystone 域是高级别的安全界限，逻辑上对项目、用户和组进行分组。因此，它们可用于集中管理所有基于 keystone 的身份组件。随着帐户域的引入，服务器、存储和其他资源现在可以逻辑地分组到多个项目（以前称为租户），后者本身可以分组到一个类似于 master 帐户的容器中。此外，可以在帐户域中管理多个用户，并分配对每个项目不同的角色。

Identity V3 API 支持多个域。不同域的用户可能会在不同的身份验证后端中表示。它们甚至可能具有不同的属性，它们必须映射到一组角色和特权，这些属性在策略定义中使用，以访问各种服务资源。

如果规则只能指定对 admin 用户和属于项目的用户的访问权限，则映射可能很简单。在其他情况下，云管理员可能需要批准每个项目的映射例程。

特定于域的身份验证驱动程序允许使用域特定的配置文件为多个域配置 Identity 服务。启用驱动程序并设置域特定配置文件位置，发生在 /var/lib/config-data/puppet-generated/keystone/etc/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 文件中的选项。

您可以使用外部身份提供程序(IdP)向 OpenStack 服务供应商(SP)进行身份验证。在本例中，Service Providers 是 OpenStack 云提供的服务。

对于身份验证和授权服务，OpenStack 身份模型将外部身份验证数据库视为单独的 keystone 域。每个外部身份验证机制都与 keystone 域关联，支持多个共存域。您可以使用角色为外部域中的用户授予对云中资源的访问权限；这种方法也适用于跨域多项目部署。这种方法还对每个组件策略也有影响，因为并非所有 OpenStack 角色都可以在策略中映射到外部验证的用户。例如，如果外部身份验证数据库中的用户需要管理访问权限，则通常还需要额外的配置，并且需要与 admin 域中的 admin 用户类似。

外部身份验证提供了一种方式，可以使用现有凭证来访问使用一组凭证在多个授权云中提供的多个端点（如服务器、卷和数据库）的云资源，而无需多次置备额外的身份或登录。凭据由用户的身份提供程序维护。

身份服务可以将用户凭据存储在 SQL 数据库中，也可以使用与 LDAP 兼容的目录服务器。身份数据库可能独立于其他 OpenStack 服务使用的数据库，以减少存储的凭据的风险。

当您使用用户名和密码进行身份验证时，Identity 不会强制对密码强度、过期或身份验证尝试失败的策略。希望强制实施更强大的密码策略的组织应考虑使用身份扩展或外部身份验证服务。

LDAP 简化了身份验证集成到机构的现有目录服务和用户帐户管理流程中的集成。OpenStack 中的身份验证和授权策略可能会被委派给其他服务。典型的用例是寻求部署私有云的组织，并且已经在 LDAP 系统中拥有员工和数据库用户。使用这个作为身份验证授权，对 Identity 服务的请求会被委派给 LDAP 系统，然后根据其策略授权或拒绝。身份验证成功后，Identity 服务会生成用于访问授权服务的令牌。

请注意，如果 LDAP 系统为用户定义了属性，如 admin、finance 和 HR 等，则这些属性必须映射到身份内的角色和组中，以供各种 OpenStack 服务使用。/var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf 文件将 LDAP 属性映射到 Identity 属性。

身份服务(keystone)可以验证存储在基于 LDAP 的服务中的用户帐户，如 Microsoft Active Directory Domain Services (AD DS)和 Red Hat Identity Management (IdM)。在这种情况下，keystone 对 LDAP 用户数据库身份验证具有只读访问权限，并保持对分配给经过身份验证的用户的 authZ 权限的管理。authZ 功能（权限、角色、项目）仍然由 keystone 执行，其中使用 keystone 管理工具将权限和角色分配给 LDAP 帐户。

4.9.1. LDAP 集成如何工作

在下图中，keystone 使用加密的 LDAPS 连接连接到 Active Directory 域控制器。当用户登录到 horizon 时，keystone 会收到提供的用户凭证，并将其传递给 authZ 的 Active Directory。

有关将 OpenStack 与 AD DS 和 IdM 集成的详情，请参考集成指南 ：https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html-single/integrate_with_identity_service/

通常，服务的策略文件存在于 /etc/$service 目录中。例如，Compute (nova)的 policy.json 文件的完整路径为 /etc/nova/policy.json。

有两个重要的架构更改会影响到您如何找到现有策略：

默认情况下，生成的策略通过 osly.policy CLI 工具推送到 stdout。

服务策略文件语句是别名定义或规则。别名定义位于文件的顶部。以下列表包含计算(nova)生成的 policy.json 文件中别名定义的说明：

policy.json 文件支持某些操作器，以便您可以控制这些设置的目标范围。例如，以下 keystone 设置包含只有 admin 用户可以创建用户的规则：

"identity:create_user": "rule:admin_required"

: 字符左侧的部分描述了特权，右侧的 部分则定义哪些人可以使用特权。您还可以使用 Operator 来进一步控制范围：

例如，以下设置意味着没有用户有权创建新用户：

"identity:create_user": "!"

若要覆盖默认规则，请编辑相应 OpenStack 服务的 policy.json 文件。例如，Compute 服务在 nova 目录中有一个 policy.json，当您从容器内部查看时，这是容器化服务的正确位置。

要自定义 keystone 角色的权限，请更新服务的 policy.json 文件。这意味着您可以更精细地定义分配给一类用户的权限。这个示例使用以下权限 为您的部署 创建一个高级用户角色：

此角色的目的是为某些用户授予其他权限，而无需授予 admin 访问权限。要使用这些权限，您必须为自定义角色授予以下权限：

您可以创建策略，以根据发出该 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 语法选项的更多信息，请参阅策略语法。

您可以使用 Red Hat OpenStack Platform 中的工具构建每个用户和相关权限的角色分配报告。

您可以审核给定角色可以访问的 API 调用。为每个角色重复此过程将生成各个角色的可访问 API 的综合报告。对于您需要的步骤：

当您评估虚拟机监控程序平台时，请考虑管理程序要在其上运行的硬件的可支持性。此外，还要考虑硬件中提供的其他功能，以及您选择作为 OpenStack 部署一部分的虚拟机监控程序支持这些功能。为此，管理程序各自具有自己的硬件兼容性列表(HCLs)。当选择兼容硬件时，提前知道基于硬件的虚拟化技术在安全性方面非常重要。

PCI 透传允许实例直接访问节点上的某一硬件。例如，这可用于允许实例访问视频卡或 GPU，为高性能计算提供计算的统一设备架构(CUDA)。这个功能涉及两种类型的安全风险：直接内存访问和硬件延迟。

直接内存访问(DMA)是允许某些硬件设备访问主机计算机中任意物理内存地址的功能。视频卡通常具有此功能。但是，不应为实例指定任意物理内存访问，因为它可以完全查看同一节点上运行的主机系统和其他实例。硬件供应商使用输入/输出内存管理单元(IOMMU)来管理 DMA 访问。您应该确认管理程序已配置为使用此硬件功能。

当实例对固件或某个设备的一部分进行恶意修改时，会发生硬件检测。由于此设备由其他实例或主机操作系统使用，因此恶意代码可能会分散到这些系统。最终结果是，一个实例可以在其安全区外运行代码。这是一个重大的破坏，因为难以重置物理硬件的状态，并可能导致其他暴露，如访问管理网络。

由于与 PCI 透传关联的风险和复杂性，应默认禁用它。如果为特定需要启用，则需要适当的进程，以帮助确保在重复使用前清理硬件。

强制访问控制通过限制 QEMU 进程的权限限制为仅需要什么内容来限制尝试攻击的影响。在 Red Hat OpenStack Platform 上，SELinux 配置为以单独的安全上下文运行每个 QEMU 进程。SELinux 策略已预先配置为 Red Hat OpenStack Platform 服务。

OpenStack 的 SELinux 策略旨在帮助保护虚拟机监控程序主机和虚拟机免受两个主要威胁向量：

无论虚拟机中运行的客户机操作系统是什么，都提供了红帽的基于 SELinux 的隔离。可以使用 Linux 或 Windows 虚拟机。

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

system_u:object_r:svirt_image_t:s0:c87,c520 image1
system_u:object_r:svirt_image_t:s0:419,c172 image2

有些服务（如 nova、glance 和 keystone）现在在容器内运行。这种方法有助于通过更轻松地将更新应用到服务来提高安全性。在其自己的容器中运行每个服务还提高了在同一裸机上共存的服务之间的隔离。如果任何一个服务受到攻击的影响，这非常有用，这可以防止对相邻服务进行轻松访问。

如果您要更新任何配置文件，则考虑某些管理实践，假定容器化服务是临时的：

相反，如果您需要为容器化服务添加任何更改，则需要更新用于看到容器的配置文件。这些文件在初始部署期间由 puppet 生成，并包含对云运行很重要的敏感数据，应相应地处理。它们存储在 /var/lib/config-data/puppet-generated/ 中。例如：

容器重启后将应用对这些文件所做的任何更改。

任何 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 目录，因为它与该节点上运行的每个实例的组合空间相同。如果您的部署需要完整的虚拟机备份，则需要确保成功备份该目录。

物理服务器使用复杂的固件来启用和操作服务器硬件，以及轻型管理卡，它们可能有自己的安全漏洞，从而可能允许系统访问和中断。为了解决这个问题，硬件供应商会发布固件更新，这些更新与操作系统更新分开安装。您需要一个可操作的安全进程，在常规时间表上检索、测试并实现这些更新，请注意，固件更新通常需要重新启动物理主机才能生效。

OpenStack Block Storage (cinder)是一种向自助服务提供软件（服务和库）的服务，用于管理永久的块级存储设备。这会创建按需访问块存储资源，以用于 Compute (nova)实例。这通过将块存储池虚拟化为各种后端存储设备（可以是软件实施或传统硬件存储产品）来创建软件定义型存储。这的主要功能是管理块设备的创建、附加和分离。消费者不需要了解后端存储设备的类型或其所在的位置。

计算实例使用行业标准存储协议（如 iSCSI、ATA over Ethernet 或 Fibre-Channel）存储和检索块存储。这些资源可使用 OpenStack 原生标准 HTTP RESTful API 管理和配置。

sudo ls -l /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
-rw-r-----. 1 root 42407 188012 Dec 11 09:34 /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf
root UNKNOWN

sudo docker exec -it cinder_api stat -L -c "%U %G" /etc/cinder/cinder.conf
root cinder

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/cinder/etc/cinder/cinder.conf

OpenStack Networking 服务(neutron)使最终用户或项目能够定义和使用网络资源。OpenStack 网络提供了一个面向项目的 API，用于定义云中实例的网络连接和 IP 寻址，除了编排网络配置之外。通过过渡到以 API 为中心的网络服务，云架构师和管理员应考虑确保物理和虚拟网络基础架构和服务的良好实践。

OpenStack 网络采用插件架构设计，通过开源社区或第三方服务提供 API 的可扩展性。当您评估您的架构设计要求时，务必要确定 OpenStack 网络核心服务中提供的功能、第三方产品提供的任何其他服务，以及在物理基础架构中实施哪些补充服务。

本节概述了实施 OpenStack 网络时应考虑的流程和良好做法。

6.8.1. 网络架构

OpenStack 网络是一种独立服务，可在多个节点上部署多个进程。这些流程相互交互和其他 OpenStack 服务。OpenStack 网络服务的主要流程是 neutron-server，它是公开 OpenStack 网络 API 的 Python 守护进程，并将项目请求传递给一组插件以进行额外的处理。

OpenStack 网络组件有：

• Neutron 服务器(neutron-server 和 neutron-*-plugin) - neutron-server 服务在 Controller 节点上运行，为网络 API 及其扩展（或插件）提供服务。它还强制执行每个端口的网络模型和 IP 地址。neutron-server 需要直接访问持久数据库。代理可以通过 neutron-server 间接访问数据库，它们使用 AMQP （高级消息队列协议）进行通信。
• Neutron 数据库 - 数据库是 neutron 信息的集中式来源，API 记录数据库中的所有事务。这允许多个 Neutron 服务器共享相同的数据库集群，保持它们同步，并允许持久性网络配置拓扑。
• 插件代理(neutron-*-agent) - 在每个计算节点和网络节点（与 L3 和 DHCP 一起）上运行，以管理本地虚拟交换机(vswitch)配置。启用的插件决定了哪些代理被启用。这些服务需要消息队列访问，并且根据所使用的插件来访问外部网络控制器或 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) - 提供用于应用实例操作系统配置和用户提供的初始脚本('userdata')的元数据服务。该实施要求在 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 和 plugin-agents 交互。

下图显示了 OpenStack 网络组件的架构和网络流图：

请注意，当使用分布式虚拟路由(DVR)和第 3 层高可用性(L3HA)时，此方法会有很大变化。这些模式改变了 neutron 的安全环境，因为 L3HA 在路由器之间实现 VRRP。部署需要正确调整大小和强化，以帮助缓解对路由器的 DoS 攻击，以及路由器之间的本地网络流量必须被视为敏感，以帮助解决 VRRP 欺骗的问题。DVR 将网络组件（如路由）移到 Compute 节点，同时仍需要网络节点。因此，计算节点需要访问和从公共网络访问，从而增加其暴露，并要求客户需要额外的安全考虑，因为它们需要确保防火墙规则和安全模型支持此方法。

6.8.2. 物理服务器上的 Neutron 服务放置

本节介绍包含控制器节点、网络节点和一组用于运行实例的计算节点的标准架构。要为物理服务器建立网络连接，典型的 neutron 部署具有四个不同的物理数据中心网络：

• 管理网络 - 用于 OpenStack 组件之间的内部通信。此网络上的 IP 地址应该只在数据中心内访问，并被视为 Management Security 区域。默认情况下，Management network 角色由 Internal API 网络执行。
• 客户机网络 - 用于云部署内的虚拟机数据通信.此网络的 IP 寻址要求取决于所使用的 OpenStack 网络插件，以及项目提出的虚拟网络的网络配置选择。此网络被视为 Guest Security 区域。
• 外部网络 - 在某些部署场景中为虚拟机提供互联网访问。此网络上的 IP 地址应该可以被 Internet 上的任何人访问。此网络被视为位于公共安全区中。此网络由 neutron External 网络提供。这些 neutron VLAN 托管在外部网桥上。它们不是由 Red Hat OpenStack Platform director 创建，而是在部署后由 neutron 创建。
• 公共 API 网络 - 向项目公开所有 OpenStack API，包括 OpenStack 网络 API。此网络上的 IP 地址应该可以被 Internet 上的任何人访问。这可能与外部网络相同，因为可以为外部网络创建一个使用 IP 分配范围小于 IP 块中完整范围的 IP 地址范围的子网。此网络被视为位于公共安全区中。

建议您将此流量划分为单独的区。如需更多信息，请参阅下一章节。

6.8.3. 安全区

建议您使用安全区的概念来保持关键系统相互独立。在实际意义上，这意味着使用 VLAN 和防火墙规则隔离网络流量。该短语以细致的细节完成，结果应该是只有需要连接到 neutron 的服务才能这样做。

在下图中，您可以看到已创建区来分离某些组件：

• 仪表板：可以访问公共网络和管理网络。
• Keystone：可以访问管理网络。
• Compute 节点：可以访问管理网络和计算实例。
• 网络节点： 可根据所使用的 neutron-plugin 访问管理网络、计算实例和可能公共网络。
• SDN 服务节点：管理服务、计算实例，以及可能根据使用和配置的公共产品。

.

# Address to bind the API server
bind_host = IP ADDRESS OF SERVER

# Port the bind the API server to
bind_port = 9696

quota_driver = neutron.db.quota_db.DbQuotaDriver

sudo ls -l /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
-rw-r-----. 1 root 42435 41748 Dec 11 09:34 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

sudo stat -L -c "%U %G" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf
root UNKNOWN

sudo docker exec -it neutron_api stat -L -c "%U %G" /etc/neutron/neutron.conf
root neutron

$ stat -L -c "%a" /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf

在整个机构中，对操作和安全需求都很重要：

网络时间协议(NTP)以分级设计进行组织。每个层称为 stratum。在层次结构的顶部是 stratum 0 设备，如原子时钟。在 NTP 层次结构中，Straum 0 设备为公开可用的级别 1 和 stratum 2 NTP 时间服务器提供参考。

不要将数据中心客户端直接连接到公开可用的 NTP stratum 1 或 2 服务器。直接连接的数量会对公共 NTP 资源造成不必要的压力。相反，在您的数据中心中分配一个专用时间服务器，并将客户端连接到该专用服务器。

将实例配置为从专用时间服务器（而不是它们所在的主机）接收时间。

您可以设置标语，向通过 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 部署命令，如下所示：& lt;full environment > 表示您仍然必须包含所有原始部署参数。例如：

    openstack overcloud deploy --templates \
      -e <full environment> -e  ssh_banner.yaml

维护所有审计事件的记录可帮助您建立系统基准、执行故障排除或分析导致特定结果的事件序列。审计系统可以记录许多类型的事件，如更改系统时间、强制/诊断访问控制的更改，以及创建/删除用户或组。

可以使用环境文件创建规则，然后由 director 注入到 /etc/audit/audit.rules 中。例如：

    resource_registry:
      OS::TripleO::Services::Auditd: /usr/share/openstack-tripleo-heat-templates/puppet/services/auditd.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  : 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

可以为规则设置以下参数：

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 配置文件可用属性的完整列表，请参见 的 AIDE MAN 页面（https://aide.github.io/）。

完成以下内容以将更改应用到您的部署：

    MyAlias = p+i+n+u+g+s+b+m+c+sha512

securetty 允许您禁用任何控制台设备(tty)的 root 访问权限。此行为由 /etc/securetty 文件中的条目管理。例如：

  resource_registry:
    OS::TripleO::Services::Securetty: ../puppet/services/securetty.yaml

  parameter_defaults:
    TtyValues:
      - console
      - tty1
      - tty2
      - tty3
      - tty4
      - tty5
      - tty6

全面的审计流程可帮助您检查 OpenStack 部署的持续安全性。这对 keystone 尤为重要，因为其在安全模型中的角色。

Red Hat OpenStack Platform 采用 Cloud Auditing Data Federation (CADF)作为审计事件的数据格式，keystone 服务为 Identity 和 Token 操作生成 CADF 事件。您可以使用 KeystoneNotificationFormat 为 keystone 启用 CADF 审计：

  parameter_defaults:
    KeystoneNotificationFormat: cadf

要强制对新系统用户（非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

本节论述了在部署 Dashboard (horizon)服务前需要考虑的安全问题。

本章论述了如何帮助缓解一些常见 Web 服务器漏洞。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

enable_secure_proxy_ssl_header: true

仪表板依赖于一些安全功能的共享 SECRET_KEY 设置。secret 密钥应该是随机生成的字符串，至少 64 个字符，它必须在所有活跃的仪表板实例间共享。对这个密钥的威胁可能会允许远程攻击者执行任意代码。轮转此密钥会导致现有用户会话和缓存无效。不要将此密钥提交到公共存储库。

对于 director 部署，此设置作为 HorizonSecret 值进行管理。

控制面板会话 Cookie 可以通过浏览器技术（如 JavaScript）进行交互。对于随处 TLS 的 director 部署，您可以使用 HorizonSecureCookies 设置强化此行为。

仪表板的静态介质应部署到仪表板域的子域并由 Web 服务器提供。还可以接受使用外部内容交付网络(CDN)。此子域不应设置 Cookie 或提供用户提供的内容。介质还应通过 HTTPS 提供。

仪表板的默认配置使用 django_compressor 在提供之前压缩和减去 CSS 和 JavaScript 内容。这个过程应该在部署仪表板前静态完成，而不是使用默认的 in-request 动态压缩，并与部署的代码或 CDN 服务器一起复制生成的文件。应在非生产构建环境中进行压缩。如果这不实际，请考虑完全禁用资源压缩。不应在生产环境中安装在线压缩依赖项（无 Node.js）。

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.yaml

以下设置默认设置为 True，但可以根据需要使用环境文件来禁用它。

Dashboard 的 local_settings.py 文件中的 ENFORCE_PASSWORD_CHECK 设置在 Change Password 表单上显示一个 Admin Password 字段，这有助于验证管理员是否启动密码更改。

您可以使用环境文件禁用 ENFORCE_PASSWORD_CHECK ：

    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false

DISALLOW_IFRAME_EMBED 设置不允许在 iframe 中嵌入仪表板。旧浏览器仍容易受到 Cross-Frame Scripting (XFS)漏洞的影响，因此此选项可以为不需要的部署添加额外的安全强化。默认设置为 True，但可以根据需要使用环境文件来禁用它。例如，您可以使用以下参数允许 iframe 嵌入：

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

以下设置默认设置为 True，但可以根据需要使用环境文件来禁用它。

密码显示按钮可在仪表板上查看他们要输入的密码。可以使用 DISABLE_PASSWORD_REVEAL 参数切换这个选项：

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

许多管制行业，如 HIPAA、PCI-DSS 和美国。政府，要求您显示用户登录横幅。控制面板服务在容器内运行，因此您需要自定义 Dashboard 容器镜像以应用横幅。有关自定义 Dashboard 容器的更多信息，请参阅 https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html-single/introduction_to_the_openstack_dashboard/index#dashboard-customization。

您可以选择配置仪表板来限制文件上传的大小；此设置可能需要各种安全强化策略。

LimitRequestBody - 这个值（以字节为单位）限制您可以使用仪表板（如镜像和其他大型文件）传输的文件的最大大小。

例如，此设置将每个文件上传限制为最大 10 GB (10737418240)。您需要调整这个值以适合您的部署。

建议在生产环境中将 DEBUG 设置保留为 False。如果设置为 True，则 Django 可能会输出堆栈追踪到包含敏感 Web 服务器状态信息的浏览器用户。此外，DEBUG 模式具有禁用 ALLOWED_HOSTS 的影响，这可能是不必要的结果，具体取决于您的要求。

Manila 通过 keystone 注册，允许您使用 manila 端点 命令找到 API。例如：

 $ manila endpoints
 +-------------+-----------------------------------------+
 | manila      | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v1/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v1/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v1/20787a7b...|
 | id          | 82cc5535aa444632b64585f138cb9b61        |
 +-------------+-----------------------------------------+

 +-------------+-----------------------------------------+
 | manilav2    | Value                                   |
 +-------------+-----------------------------------------+
 | adminURL    | http://172.18.198.55:8786/v2/20787a7b...|
 | region      | RegionOne                               |
 | publicURL   | http://172.18.198.55:8786/v2/20787a7b...|
 | internalURL | http://172.18.198.55:8786/v2/20787a7b...|
 | id          | 2e8591bfcac4405fa7e5dc3fd61a2b85        |
 +-------------+-----------------------------------------+

默认情况下，manila API 服务仅侦听端口 8786，其支持 IPv4 和 IPv6。

Manila 使用多个配置文件；这些文件存储在 /var/lib/config-data/puppet-generated/manila/ 中：

 api-paste.ini
 manila.conf
 policy.json
 rootwrap.conf
 rootwrap.d

 ./rootwrap.d:
 share.filters

建议您将 manila 配置为以非 root 服务帐户运行，并更改文件权限，以便只有系统管理员可以修改它们。Manila 期望只有管理员能够写入配置文件，服务只能通过 manila 组中的组成员身份来读取它们。其他用户不能读取这些文件，因为它们包含服务帐户密码。

manila 中的共享驱动程序是一个 Python 类，可以为后端设置来管理共享操作，其中一些特定于供应商。后端是 manila-share 服务的实例。Manila 具有许多不同的存储系统的共享驱动程序，支持商业供应商和开源解决方案。每个共享驱动都支持一个或多个后端模式： 共享服务器，无共享服务器。管理员使用 driver_handles_share_servers 在 manila.conf 中指定它来选择模式。

共享服务器是导出共享文件系统的逻辑网络附加存储(NAS)服务器。现在，后端存储系统非常复杂，可以隔离不同 OpenStack 项目之间的数据路径和网络路径。

在属于创建项目用户的隔离网络上创建由 manila 共享驱动程序置备的共享服务器。共享 服务器模式可以配置扁平网络或网段网络，具体取决于网络提供程序。

对于不同的模式，可以使用不同的驱动程序来使用相同的硬件。根据所选模式，您可能需要通过配置文件提供额外的配置详情。

每个共享驱动程序支持至少一个可用驱动程序模式：

无共享服务器模式 - 在这个模式中，驱动程序将不会设置共享服务器，因此不需要设置任何新的网络接口。假设由驱动程序管理的存储控制器具有需要的所有网络接口。驱动程序直接创建共享，而无需之前创建共享服务器。要使用在这个模式下运行的驱动程序创建共享，manila 不需要用户创建任何私有共享网络。

在没有共享服务器 模式中，共享驱动程序无法处理共享服务器生命周期。管理员应该处理可能需要提供项目隔离所需的存储、网络和其他主机侧配置。在此模式中，管理员可以将存储设置为导出共享的主机。OpenStack 云中的所有项目共享一个通用的网络管道。缺少隔离可能会影响安全性和服务质量。当使用不处理共享服务器的共享驱动程序时，云用户无法确保不可信用户通过树形访问其共享，可以遍历其文件系统的顶级目录。在公共云中，所有网络带宽都由一个客户端使用，因此管理员应该小心谨慎。网络平衡可以由任何方法实现，而不一定要借助 OpenStack 工具。

共享服务器模式 - 在此模式中，驱动程序可以创建共享服务器并将其插入到现有的 OpenStack 网络。Manila 确定是否需要新的共享服务器，并提供共享驱动程序所需的所有网络信息来创建必要的共享服务器。

在处理共享服务器的驱动程序模式中创建共享时，用户必须提供一个共享网络，以便他们希望导出其共享。Manila 使用此网络为此网络上的共享服务器创建网络端口。

用户可以在共享服务器中配置 安全服务，且没有 共享服务器 后端模式。但是，如果没有共享服务器 后端模式，管理员必须在主机上手动设置所需的身份验证服务。在 共享服务器 模式中，manila 可以配置用户在其生成的共享服务器上识别的安全服务。

Manila 可以与不同的网络类型集成： flat、GRE、VLAN、VXLAN。

在 共享服务器 后端模式中，共享驱动程序为每个共享网络创建和管理共享服务器。这个模式可以分为两个变体：

用户可以使用 OpenStack Networking (neutron)服务中的网络和子网来创建共享网络。如果管理员决定使用 StandAloneNetworkPlugin，则用户不需要提供任何网络信息，因为管理员在配置文件中预配置此设置。

创建共享网络后，manila 检索由网络提供程序确定的网络信息：网络类型、分段标识符（如果网络使用分段）和 CIDR 表示法中分配网络的 IP 块。

用户可以创建指定安全要求的安全服务，如 AD 或 LDAP 域或 Kerberos 域。Manila 假定创建共享服务器的子网可以访问在安全服务中引用的任何主机，这限制了可以使用此模式的情况数量。

Manila 可以通过与网络身份验证协议集成来限制对文件共享的访问。每个项目都可以有自己的身份验证域，域独立于云的 Keystone 身份验证域。此项目域可用于向 OpenStack 云中运行的应用提供授权(AuthZ)服务，包括 manila。可用的身份验证协议包括 LDAP、Kerberos 和 Microsoft Active Directory 身份验证服务。

用户可以指定哪些特定客户端有权访问其创建的共享。由于 Keystone 服务，由各个用户创建的共享仅对同一项目中本身和其他用户可见。Manila 允许用户创建"公开"可见的共享。这些共享在属于其他 OpenStack 项目的用户的仪表板中可见，如果所有者授予访问权限，它们甚至可以挂载这些共享（如果它们可从网络访问）。

在创建共享时，使用 key --public 为您的其他项目共享公共，以便在共享列表中看到它，并查看其详细信息。

根据 policy.json 文件，管理员和共享所有者的用户可以通过创建访问规则来管理对共享的访问。使用 manila access-allow、manila access-deny 和 manila access-list 命令，您可以相应地授予、拒绝和列出对指定共享的访问权限。

当只创建共享时，没有与其关联的默认访问规则，并挂载它的权限。这可以在挂载配置中使用导出协议中看到。例如，存储上存在一个 NFS 命令 exportfs 或 /etc/exports 文件，该文件控制每个远程共享并定义可以访问它的主机。如果 nobody 可以挂载共享，则为空。对于远程 CIFS 服务器，有一个 net conf list 命令可以显示配置。hosts deny 参数应由共享驱动程序设置为 0.0.0.0/0，这意味着拒绝任何主机挂载共享。

使用 manila，您可以通过指定这些支持的共享访问级别之一来允许或拒绝对共享的访问：

您还必须指定以下支持的身份验证方法之一：

要验证是否为共享正确配置了访问规则(ACL)，您可以列出其权限。

共享类型是一个由管理员定义的服务类型（type of service），它包括一个项目可见的描述信息，以及一个项目不可见的、称为额外规格（extra specifications）的键值对列表。manila-scheduler 使用额外的规格来做出调度决策，驱动程序控制共享创建。

管理员可以创建和删除共享类型，也可以管理额外规格在 manila 中赋予它们的含义。项目可以列出共享类型，并可使用它们来创建新共享。共享类型可以被创建为 public 和 private。这是定义其他项目是否可以在共享类型列表中看到的共享类型的可见性级别，并使用它来创建新共享。

默认情况下，共享类型创建为公共。在创建共享类型时，使用 --is_public 参数设置为 False 来使您的共享类型私有设为私有，这将阻止其他项目在共享类型列表中看到它，并使用它创建新的共享。另一方面，公共 共享类型可供云中的每个项目使用。

Manila 允许管理员为项目授予或拒绝对 私有 共享类型的访问权限。您还可以获取有关指定私有共享类型访问权限的信息。

例如，admin 项目中的管理员用户可以创建名为 my_type 的专用共享类型，并在列表中看到它。在下面的控制台示例中，会省略了登录和注销，并且提供了环境变量来显示当前登录的用户。

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

demo 项目中的 demo 用户可以列出类型，但名为 my_type 的私有共享类型对他不可见。

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs             | optional_extra_specs |
 +----+--------+-----------+-----------+----------------------------------+----------------------+
 | 5..| default| public    | YES       | driver_handles_share_servers:True| snapshot_support:True|
 +----+--------+-----------+-----------+----------------------------------+----------------------+

管理员可以为 demo 项目授予专用共享类型的访问权限，其项目 ID 等于 df29a37db5ae48d19b349fe947fada46 ：

 $ env | grep OS_
 ...
 OS_USERNAME=admin
 OS_TENANT_NAME=admin
 ...
 $ openstack project list
 +----------------------------------+--------------------+
 | ID                               | Name               |
 +----------------------------------+--------------------+
 | ...                              | ...                |
 | df29a37db5ae48d19b349fe947fada46 | demo               |
 +----------------------------------+--------------------+
 $ manila type-access-add my_type df29a37db5ae48d19b349fe947fada46

因此，demo 项目中的用户可以查看私有共享类型，并在创建共享时使用它：

 $ env | grep OS_
 ...
 OS_USERNAME=demo
 OS_TENANT_NAME=demo
 ...
 $ manila type-list --all
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | ID | Name   | Visibility| is_default| required_extra_specs              | optional_extra_specs  |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
 | 4..| my_type| private   | -         | driver_handles_share_servers:False| snapshot_support:True |
 | 5..| default| public    | YES       | driver_handles_share_servers:True | snapshot_support:True |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+

要拒绝对指定项目的访问，请使用 manila type-access-remove <share_type> <project_id>。

共享文件系统服务 API 使用基于角色的访问控制策略进行设计。这些策略决定了哪些用户能够以某种方式访问某些 API，并在服务的 policy.json 文件中定义。

每当向 manila 发出 API 调用时，策略引擎使用适当的策略定义来确定是否可以接受调用。策略规则决定在哪些情况下允许 API 调用。当规则是空字符串： "" 时，/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json 文件具有始终允许的操作的规则： ""；基于用户角色或规则的规则。以下是 manila 的 policy.json 文件的片段。预计在 OpenStack 版本之间可能会有变化。

   {
       "context_is_admin": "role:admin",
       "admin_or_owner": "is_admin:True or project_id:%(project_id)s",
       "default": "rule:admin_or_owner",
       "share_extension:quotas:show": "",
       "share_extension:quotas:update": "rule:admin_api",
       "share_extension:quotas:delete": "rule:admin_api",
       "share_extension:quota_classes": "",
   }

用户必须分配给您在策略中引用的组和角色。使用用户管理命令时，服务会自动完成。

对 swift 的安全强化开始保护网络组件。如需更多信息，请参阅网络章节。

为了高可用性，使用 rsync 协议在存储服务节点间复制数据。此外，在客户端端点和云环境之间转发数据时，代理服务与存储服务通信。

这要求代理节点具有两个接口（物理或虚拟）：

下图演示了一个可能的网络架构，它使用具有管理节点(OSAM)的对象存储网络架构：

以下是各种存储服务的默认侦听端口：

代理节点应至少有两个接口（物理或虚拟）：一个公共和一个私有接口。您可以使用防火墙或服务绑定来帮助保护公共接口。面向公众的服务是一种 HTTP Web 服务器，用于处理端点客户端请求、验证它们并执行适当的操作。私有接口不需要任何侦听的服务，而是用来建立与私有存储网络上的存储节点的传出连接。

Object Storage (swift)使用 WSGI 模型来为中间件功能提供，不仅提供通用可扩展性，也用于对端点客户端进行身份验证。身份验证提供程序定义存在哪些角色和用户类型。有些使用传统的用户名和密码凭证，另一些可能会利用 API 密钥令牌甚至客户端 x.509 证书。自定义供应商可以使用自定义中间件进行集成。

对象存储默认附带两个身份验证中间件模块，其中任一模块可用作开发自定义身份验证中间件的示例代码。

Swift 可以与 Barbican 集成，以透明加密和解密存储(at-rest)对象。at-rest 加密与传输中的加密不同，引用在磁盘上存储的同时加密的对象。

Swift 以透明方式执行这些加密任务，对象在上传到 swift 时自动加密，然后在提供给用户时自动解密。此加密和解密使用同样的(symmetric)密钥进行，该密钥存储在 Barbican 中。

如需更多信息，请参阅 Barbican 集成指南： https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html-single/manage_secrets_with_openstack_key_manager/

在每个节点上的 /var/lib/config-data/puppet-generated/swift/etc/swift/swift.conf 中，有一个 swift_hash_path_prefix 设置和 swift_hash_path_suffix 设置。提供了它们，以减少所存储对象的哈希冲突几率，一个用户会覆盖另一个用户的数据。

这个值应该最初使用加密安全随机数字生成器设置，并在所有节点中保持一致。确保它具有正确的 ACL，并且您有备份副本以避免数据丢失。

集中式日志记录系统是入侵者的高值目标，因为成功漏洞可能会允许他们通过记录的事件清除或篡改。建议您使用以下命令强化监控平台。此外，请考虑定期备份这些系统，并在出现中断或 DoS 时进行故障转移规划。

事件监控是一种更主动的方法来保护环境，提供实时检测和响应。存在多个工具，有助于监控。对于 OpenStack 部署，您需要监控硬件、OpenStack 服务和云资源的使用情况。

本节描述了您可能需要了解的一些示例事件。

为了减少用户、项目或域删除用户、项目或域删除中的安全风险，讨论了系统中的通知，并让 OpenStack 组件根据终止实例、断开 CPU 和存储资源等情况来响应这些事件。

安全监控控制，如入侵检测软件、防病毒软件和清除软件检测和删除工具可生成日志，显示攻击或入侵发生的时间和方式。这些工具可以在 OpenStack 节点上部署时提供一层保护。项目用户可能还想在其实例上运行此类工具。

本节介绍 OpenStack 部署中数据隐私的一些问题。

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.

对于裸机置备基础架构，您应该考虑安全强化基板管理控制器(BMC)，特别是 IPMI。例如，您可以在 provisioning 网络中隔离这些系统，配置非默认和强大的密码，以及禁用不需要的管理功能。如需更多信息，请参阅厂商强化这些组件的指导。

存在 选项，用于加密项目数据（无论其存储在磁盘上或通过网络传输），如下面描述的 OpenStack 卷加密功能。在将自己的数据发送到其供应商之前，这比一般建议用户对自己的数据进行加密。

代表项目加密数据的重要性主要与攻击者可以访问项目数据的供应商承担的风险相关。政府可能提出要求，以及每个策略的要求，在私人合同中，甚至针对公共云提供商的私人合同而遵守相关的要求。在选择项目加密策略前，请考虑获取风险评估和法律建议。

每个实例或每个对象加密更首选，按项目降序、每个项目、每主机和云聚合进行降序排列。本建议与实施的复杂性和难度相反。目前，在某些项目中，很难或不可能实施加密，如每个项目也是如此。实施者应该优先考虑加密项目数据。

通常，数据加密与可靠地销毁项目和每个实例数据（只要丢弃密钥）紧密相关。请注意，在这样做时，以可靠和安全的方式销毁这些密钥非常重要。

存在为用户加密数据的机会：

为了解决项目数据隐私经常提及的问题，OpenStack 社区中会非常关注，使数据加密更为普遍。最终用户在将其数据保存到云之前比较简单，而这是项目对象（如媒体文件、数据库存档等）的可行路径。在某些情况下，客户端加密用于加密由需要客户端交互的虚拟化技术（如显示密钥）保存的数据，以解密数据以供以后使用。

barbican 可以帮助项目更无缝地加密数据，并使其可以访问，而无需给用户带来密钥管理。作为 OpenStack 的一部分提供加密和密钥管理服务，可简化数据恢复的采用，并有助于解决客户对隐私或滥用数据的问题。

卷加密和临时磁盘加密功能依赖于密钥管理服务（如 barbican）来创建和安全强化密钥的存储。

本章使用术语 熵 来指代实例可用的随机数据的质量和来源。加密技术通常依赖于随机性，这要求从高质量的熵池中提取。实例通常难以获得足够的熵来支持这些操作；这称为熵。此条件可以在实例中作为看似不相关的操作而定。例如，引导时间较慢的原因可能是等待 SSH 密钥生成的实例。此条件还可能会使用户从实例内部使用较差质量熵源的风险，从而使应用程序在云中运行的总体安全。

需要的是，您可以通过为实例提供高质量熵来源来帮助解决这些问题。这可以通过在云中有足够的硬件随机数生成器(HRNG)来支持实例。在这种情况下，有足够的内容特定于域。对于日常操作，现代 HRNG 可能会生成足够的熵来支持 50-100 计算节点。高带宽 HRNG，如 Intel Ivy Bridge 和较新的处理器可用的 RdR 和指令可能会处理更多节点。对于给定的云，架构师需要了解应用要求，以确保有足够的熵。

Virtio RNG 是一个随机数字生成器，默认使用 /dev/random 作为熵的来源。它还可以配置为使用硬件 RNG 或熵收集守护进程(EGD)等工具来提供一种通过部署公平地分发熵的方法。您可以使用 hw_rng 元数据属性在实例创建时启用 Virtio RNG。

在创建实例之前，必须选择镜像实例化的主机。此选择由 nova-scheduler 执行，它决定了如何分配计算和卷请求。

FilterScheduler 是计算的默认调度程序，但存在其他调度程序。这个功能与 filter hints 协同工作，用于确定应当启动实例的位置。通过这种主机选择流程，管理员可以满足许多不同的安全性和合规性要求。如果数据隔离是主要关注，您可以选择让项目实例尽可能驻留在同一主机上。相反，出于可用性或容错原因，您可以尝试使实例驻留在许多不同的主机上。

过滤器调度程序位于以下主要类别下：

可以同时应用多个过滤器。例如，ServerGroupAffinity 过滤器检查是否在特定主机的成员上创建实例，并且 ServerGroupAntiAffinity 过滤器检查是否没有在另一组主机上创建相同的实例。请注意，这两个过滤器通常同时启用，并且永远不会相互冲突，因为它们每次检查给定属性的值时都不能为 true。

在云环境中，用户处理预安装的镜像或他们上传的映像。在这两种情况下，用户都应该能够确保它们使用的镜像没有被篡改。能够验证镜像是安全性的基础。需要信任链，从镜像源到使用它的目的地。这可以通过对从可信源获取的镜像签名，并在使用前验证签名来实现。下面将讨论获取和创建验证的镜像的各种方法，然后介绍镜像签名验证功能。

<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>

OpenStack 和底层虚拟化层为 OpenStack 节点之间的镜像实时迁移提供，允许您无缝地执行 Compute 节点的滚动升级，而无需实例停机时间。但是，实时迁移也存在重大风险。要了解涉及的风险，以下是实时迁移过程中执行的高级步骤：

"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",

实例是能够在主机之间复制的服务器镜像。因此，最好在物理和虚拟主机之间应用日志。应该记录操作系统和应用程序事件，包括访问主机和数据的事件、用户添加和删除、特权更改等等。考虑将结果导出到收集日志事件的日志聚合器，与它们相关联进行分析，并存储它们以对其进行参考或进一步操作。一个常见的工具是 ELK 堆栈或 Elasticsearch、Logtash 和 Kibana。

您需要进一步确定哪些事件将触发随后发送到操作响应器的警报。

如需更多信息，请参阅 监控工具配置指南

本节讨论 OpenStack 中使用的三个最常见消息队列解决方案的安全强化方法：RabbitMQ 和 Qpid。

基于 AMQP 的解决方案(Qpid 和 RabbitMQ)支持使用 TLS 的传输级别安全性。

考虑为您的消息队列启用传输级别加密。将 TLS 用于消息传递客户端连接可保护通信不受篡改，并将通信转换至消息传递服务器。下文包含有关如何为两个流行消息传递服务器配置 TLS 的下方： Qpid 和 RabbitMQ。在配置消息传递服务器用来验证客户端连接的可信证书颁发机构(CA)捆绑包时，建议只限于用于您的节点的 CA，最好是内部管理的 CA。可信 CA 的捆绑包将决定哪些客户端证书将被授权，并传递设置 TLS 连接的 client-server 验证步骤。

[
  {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}]}
   ]}
].

RabbitMQ 和 Qpid 提供身份验证和访问控制机制，用于控制对队列的访问。

简单身份验证和安全层(SASL)是 Internet 协议中身份验证和数据安全性的框架。除简单的用户名和密码外，RabbitMQ 和 Qpid 均提供 SASL 和其他可插入身份验证机制，从而提高安全性。虽然 RabbitMQ 支持 SASL，但 OpenStack 中的支持目前不允许请求特定的 SASL 身份验证机制。OpenStack 中的 RabbitMQ 支持通过未加密的连接或用户名和密码加 X.509 客户端证书进行用户名和密码身份验证，以建立安全的 TLS 连接。

考虑在所有 OpenStack 服务节点上为与消息传递队列的客户端连接配置 X.509 客户端证书，并在可能的情况下（目前只是 Qpid）通过 X.509 客户端证书进行身份验证。在使用用户名和密码时，应为每个服务和节点创建帐户，以便精细审核对队列的访问。

在部署前，请考虑排队服务器使用的 TLS 库。Qpid 使用 Mozilla 的 NSS 库，而 RabbitMQ 使用 Erlang 的 TLS 模块（使用 OpenSSL）。

[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

[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_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>

每个项目提供许多服务来发送和接收消息。每个发送消息的二进制文件都应该使用来自队列的消息（如果仅回复）。

消息队列服务进程应相互隔离，以及计算机上的其他进程。

本节论述了强化 API 端点的建议。

您可以使用 Red Hat Single Sign-On (RH-SSO)来联合您的 IdM 用户进行 OpenStack 身份验证(authN)。通过联邦，您的 IdM 用户无需向任何 OpenStack 服务公开凭据，即可登录 OpenStack 控制面板。相反，当 Dashboard 需要用户的凭证时，它会将用户转发到 Red Hat Single Sign-On (RH-SSO)，并允许他们在其中输入其 IdM 凭证。因此，RH-SSO 会返回到用户成功通过身份验证的 Dashboard，然后允许用户访问项目。

本节描述了 keystone、RH-SSO 和 IdM 如何相互交互。OpenStack 中的联邦使用身份提供程序和服务提供商的概念：

身份提供程序 (IdP)- 存储用户帐户的服务。在这种情况下，IdM 中保存的用户帐户使用 RH-SSO 向 Keystone 提供。

Service Provider (SP)- 需要从 IdP 中的用户进行身份验证的服务。在本例中，keystone 是授予 Dashboard 对 IdM 用户访问权限的服务提供商。

在下图中，keystone (SP)与 RH-SSO (IdP)通信，后者提供必要的 SAML2 WebSSO。RH-SSO 也可以作为其他 IdP 的通用适配器。在此配置中，您可以把 keystone 指向 RH-SSO，RH-SSO 将把请求转发到其支持的身份提供程序（称为身份验证模块），目前包括 IdM 和 Active Directory。这可以通过使用 Service Provider (SP)和身份提供程序(IdP)交换元数据来完成，然后为每个系统管理员做出信任决定。结果是 IdP 可以放心地做出断言，而 SP 然后可以接收这些断言。

如需更多信息，请参阅联邦指南： https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/13/html-single/federate_with_identity_service/