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

您可以根据机构的需求和信任级别，使用以下附加安全功能配置 director：

当您为用户授予 admin 角色时，此用户具有查看、更改、创建或删除任何项目的任何资源的权限。此用户可以创建可在项目间访问的共享资源，如公开可用的 glance 镜像或提供商网络。此外，具有 admin 角色的用户也可以创建和删除用户并管理角色。

您为其分配用户 admin 角色的项目是执行 openstack 命令的默认项目。例如，如果名为 development 的项目中的 admin 用户运行以下命令，则会在 development 项目中创建一个名为 internal-network 的网络：

openstack network create internal-network

admin 用户可以使用 --project 参数在任何项目中创建 internal-network ：

openstack network create internal-network --project testing

安全区是共享常见安全关注的资源、应用程序、网络和服务器。设计安全区，以便具有常见的身份验证和授权要求和用户。您可以根据云架构、环境中可接受的信任级别以及组织的标准化要求，根据需要定义您自己的安全区。区域及其信任要求可能会因云实例是公共、私有还是混合而有所不同。

例如，您可以将 Red Hat OpenStack Platform 的默认安装分为以下区：

运行以下命令来收集有关 Red Hat OpenStack Platform 部署物理配置的信息：

您必须仔细配置跨不同信任级别或身份验证要求的多个安全区的组件。这些连接通常是网络架构中的弱点。确保配置这些连接，以满足所连接任何区的最高信任级别的安全要求。在很多情况下，连接的区的安全性控制是主要问题，因为攻击的可能性较高。区域满足了额外的潜在攻击点，并为攻击者增加将攻击迁移到部署更敏感的部分的机会。

在某些情况下，OpenStack 操作器可能考虑在比它所在的任何区域更高的标准来保护集成点。根据上述 API 端点示例，如果这些区域没有完全隔离，则遍历来自公共区的公共 API 端点可能会以公共区为目标，或获得对管理区域中内部或管理员 API 的访问。

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

大多数类型的云部署（公共、私有或混合）都暴露于某种安全威胁。以下实践可帮助缓解安全威胁：

计算服务可以为恶意的攻击者提供 DDoS 和破坏强制攻击的工具。防止方法包括出口安全组、流量检查、入侵检测系统以及客户领导和感知。对于公共网络或可访问公共网络（如互联网）可访问的部署，请确保处理和基础架构来检测和解决出站滥用。

Red Hat OpenStack Platform (RHOSP)部署中的每个节点服务于特定的角色，无论是云的基础架构，还是提供云资源。

贡献基础架构的节点运行与云相关的服务，如消息队列服务、存储管理、监控、网络和其他服务，以支持操作和置备云。基础架构角色示例包括：

提供云资源的节点为云上运行的实例提供计算或存储容量。资源角色示例包括：

记录环境中使用的系统角色。这些角色可以在用于部署 RHOSP 的模板中识别。例如，环境中每个角色都有一个 NIC 配置文件。

您可以通过查看内省期间收集的数据来获取 Red Hat OpenStack Platform 部署的硬件信息。内省从有关 CPU、内存、磁盘等的节点收集硬件信息。

记录在 Red Hat OpenStack Platform (RHOSP)基础架构中部署的节点中使用的软件组件。在评估库、应用程序或软件中漏洞的影响时，系统数据库、RHOSP 软件服务和支持组件（如负载均衡器、DNS 或 DHCP 服务）至关重要。

PKI 的核心组件在下表中显示：

您必须获得由广泛认可的证书颁发机构(CA)签名的证书，才能公开可用的 Red Hat OpenStack Platform Dashboards 或公开可访问的 API。

您必须为每个使用 TLS 保护的端点提供 DNS 域或子域。您提供的域用于创建 CA 发布的证书。客户使用 DNS 名称访问仪表板或 API，以便 CA 能够验证端点。

红帽建议使用单独的和内部管理的 CA 来保护内部流量。这使得云部署人员能够控制其私钥基础架构(PKI)实施，并使内部系统请求、签名和部署证书变得更加容易。

您可以在 overcloud 端点上启用 SSL/TLS。由于每天配置 TLS 所需的证书数量(TLS-e)，director 与 Red Hat Identity Management (IdM)服务器集成，以充当证书颁发机构并管理 overcloud 证书。有关配置 TLS-e 的更多信息，请参阅使用 Ansible 实施 TLS-e。

要在 OpenStack 组件中检查 TLS 支持的状态，请参阅 TLS 启用状态列表。

如果要使用具有您自己的证书颁发机构的 SSL 证书，请参阅在 overcloud 公共端点中启用 SSL/TLS。

您可以使用 cipherscan 来决定部署提供的 TLS 版本。Cipherscan 可以从 https://github.com/mozilla/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 版本的支持时无法连接。因此，最好认为那些在扫描的服务器上没有启用协议的版本（和任何较低）。

红帽提供了以下信息以帮助您集成 IdM 服务器和 OpenStack 环境。

有关为 IdM 安装准备 Red Hat Enterprise Linux 的详情，请参考 安装身份管理。

运行 ipa-server-install 命令来安装和配置 IdM。您可以使用命令参数跳过交互式提示。使用以下建议，以便您的 IdM 服务器可以与您的 Red Hat OpenStack Platform 环境集成：

您必须打开 IdM 所需的防火墙端口，以启用与 Red Hat OpenStack Platform 节点的通信。如需更多信息，请参阅打开 IdM 所需的端口。

您可以使用新的 tripleo-ipa 方法在 overcloud 端点上启用 SSL/TLS，在任何位置称为 TLS (TLS-e)。由于所需的证书数量，Red Hat OpenStack Platform 与 Red Hat Identity Management (IdM)集成。当您使用 tripleo-ipa 配置 TLS-e 时，IdM 是证书颁发机构。

使用云的完全限定域名(FQDN)定义 tripleo-ipa 所需的云名称和云域参数。例如，如果 FQDN 为 overcloud.example.com，请使用以下值：

根据您的环境要求设置以下附加参数：

该功能在此发行版本中作为技术预览提供，因此不享有红帽的全面支持。它只应用于测试，不应部署在生产环境中。有关技术预览功能的更多信息，请参阅覆盖范围详细信息。

现在，您可以使用 TLS-e 加密 memcached 流量。此功能可用于 novajoin 和 tripleo-ipa ：

您可以通过增加用于为加密服务流量创建证书的私钥大小来提高安全性。默认 RHOSP 私钥大小为 2048 位，与国家标准与技术(NIST)推荐最少推荐。

在环境 heat 模板中使用这些参数，并在 overcloud 部署命令中包含模板。如果您已经部署了 overcloud，则必须使用您最初使用的相同模板重新运行相同的 openstack overcloud deploy 命令，并包含新参数以使更改生效。

在以下示例中，私钥的全局值为 4096。redis 的私钥是 2048，因为 RedisCertificateKeySize 覆盖了全局参数：

parameter_defaults:
    CertificateKeySize: '4096'
    RedisCertificateKeySize: '2048'

身份验证后，Identity 服务(keystone)：

默认情况下，每个 fernet 令牌都保持在一小时内有效。这允许用户执行一系列任务，而无需重新验证。

Fernet 是替换 UUID 令牌提供程序的默认令牌提供程序。

Red Hat OpenStack Identity 服务 (keystone) 可以识别以下实体：

您可以调整 OpenStack Identity 服务(keystone)所需的身份验证安全要求。

重复的登录尝试可能是尝试强制攻击的符号。在重复失败登录尝试后，您可以使用 Identity Service 来限制对帐户的访问。

您可以使用外部身份提供程序(IdP)向 OpenStack 服务提供商(SP)进行身份验证。SPS 是 OpenStack 云提供的服务。

当您使用单独的 IdP 时，外部身份验证凭证与其他 OpenStack 服务使用的数据库分开。这种分离降低了存储凭证中断的风险。

每个外部 IdP 都有一个一对一的映射到 OpenStack Identity 服务(keystone)域。您可以在 Red Hat OpenStack Platform 中有多个已存在的域。

外部身份验证提供了一种使用现有凭证访问 Red Hat OpenStack Platform 中的资源的方法，而无需创建额外的身份。该凭证由用户的 IdP 维护。

您可以使用 Red Hat Identity Management (IdM)和 Microsoft Active Directory Domain Services (AD DS)等 IdP 进行身份管理。在此配置中，OpenStack Identity 服务对 LDAP 用户数据库具有只读访问权限。对基于用户或组角色的 API 访问的管理由 keystone 执行。角色通过使用 OpenStack Identity 服务分配给 LDAP 帐户。

4.5.1. LDAP 集成如何工作

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

其他资源

• 将 OpenStack 身份(keystone)与 Active Directory 集成
• 将 OpenStack 身份(keystone)与红帽身份管理器(IdM)集成
• 配置 director 以使用域特定的 LDAP 后端

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

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

默认情况下，生成的策略由 oslo.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，这是从容器内查看容器化服务的文件的正确位置。

此角色的目的是为某些用户授予额外的权限，而无需授予 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 语法选项的更多信息，请参阅策略语法。

您可以使用 heat 为 overcloud 中的某些服务配置访问策略。使用以下参数在对应服务上设置策略：

要为服务配置策略，请为策略参数指定一个包含服务策略的哈希值，例如：

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

您可以审核 API 调用给定角色可以访问。为每个角色重复这个过程将导致为每个角色对可访问的 API 进行全面的报告。对于您需要的步骤：

在 overcloud 上运行的 OpenStack 服务通过其 Identity 服务(keystone)凭据进行身份验证。这些密码在初始部署过程中生成，并定义为 heat 参数。例如：

            'MistralPassword',
            'BarbicanPassword',
            'AdminPassword',
            'CeilometerMeteringSecret',
            'ZaqarPassword',
            'NovaPassword',
            'MysqlRootPassword'

您可以使用 Workflow 服务(mistral)工作流轮转服务帐户使用的密码。但是，如果密码列在 DO_NOT_ROTATE 中，则不会轮转密码，如密钥加密密钥(KEK)和 Fernet 密钥：

DO_NOT_ROTATE_LIST = (
    'BarbicanSimpleCryptoKek',
    'SnmpdReadonlyUserPassword',
    'KeystoneCredential0',
    'KeystoneCredential1',
    'KeystoneFernetKey0',
    'KeystoneFernetKey1',
    'KeystoneFernetKeys',
)

出于以下原因，这些密码位于 DO_NOT_ROTATE 列表中：

使用以下步骤轮转有资格的密码。下次通过运行 openstack overcloud deploy 命令完成堆栈更新时，会应用轮转的密码更改。在环境文件中指定的任何密码优先于使用此方法的密码更改。有关中断要求和服务影响的详情，请参考中断要求。

当您更改 overcloud 服务帐户的密码时，可能会发生中断的要求和服务影响。

在轮转密码作为堆栈更新的一部分后，旧密码将变为无效。因此，在将新密码添加到服务配置设置中时，服务无法使用 HTTP 401 错误。

此外，当您更改支持服务的密码时，您可以遇到短暂的中断，包括 MySQL、Rabx 和高可用性。

整个机构之间的一致性时间对于操作和安全需求非常重要：

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

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

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

当您评估虚拟机监控程序平台时，请考虑运行虚拟机监控程序的硬件的支持性。此外，请考虑硬件中可用的额外功能，以及如何由您选择作为 OpenStack 部署的一部分选择的 hypervisor 支持这些功能。为此，虚拟机监控程序各自都有自己的硬件兼容性列表(HCLs)。当选择兼容硬件时，务必要预先了解哪些基于硬件的虚拟化功能是非常重要的。

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

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

当实例对固件或设备的其它部分进行恶意修改时，会出现硬件 infection。由于此设备被其他实例或主机操作系统使用，恶意代码可以分散到这些系统中。最终结果是一个实例可以在其安全区外运行代码。这很严重，因为重置物理硬件的状态比虚拟硬件更困难，并可能导致额外的暴露，如对管理网络的访问。

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

安全增强型 Linux (SELinux)是强制访问控制(MAC)的一个实现。MAC 通过限制允许进程或应用程序在系统上执行的操作来限制攻击的影响。有关 SELinux 的更多信息，请参阅 SELinux 是什么？

为 Red Hat OpenStack Platform (RHOSP)服务预先配置了 SELinux 策略。在 RHOSP 上，SELinux 配置为在单独的安全上下文下运行每个 QEMU 进程。在 RHOSP 中，SELinux 策略有助于保护 hypervisor 主机和实例免受以下威胁：

在 RHOSP 中，磁盘上的实例镜像文件使用 SELinux 数据类型 svirt_image_t 标记。当实例开机时，SELinux 会将随机数字标识符附加到镜像中。随机数字标识符可以防止被破坏的 OpenStack 实例获得对其他容器的未授权访问。SELinux 能够为每个虚拟机监控程序节点上分配最多 524,288 个数字标识符。

Red Hat OpenStack Platform 附带的 OpenStack 服务在容器内运行。容器化允许在不相关依赖项的情况下进行服务的开发和升级。当服务在容器内运行时，也会包含对该服务的潜在漏洞。

您可以按照以下步骤获取环境中运行的服务的信息：

您可以更改容器重启时保留的容器化服务，但不会影响 Red Hat OpenStack Platform (RHOSP)集群的永久配置。这可用于测试配置更改，或在故障排除时启用调试级别的日志。您可以手动恢复更改。另外，在 RHOSP 集群上运行重新部署会将所有参数重置为其永久配置。

使用位于 /var/lib/config-data/puppet-generated/[service] 中的配置文件对服务进行临时更改。以下示例在 nova 服务中启用调试：

您可以使用 heat 在 Red Hat OpenStack Platform (RHOSP)服务中对容器化服务进行永久更改。使用您首次部署 RHOSP 时使用的现有模板，或创建新模板来添加到部署脚本中。在以下示例中，libvirt 的私钥大小增加到 4096。

物理服务器使用复杂的固件来启用和操作服务器硬件和轻量级管理卡，这些卡可能具有自己的安全漏洞，从而可能允许系统访问和中断。为了解决这些问题，硬件供应商将发布固件更新，这些更新与操作系统更新分开安装。您需要一个操作安全流程，用于定期检索、测试并实施这些更新，请注意固件更新通常需要重新启动物理主机才能生效。

您可以设置一个横幅，以向所有通过 SSH 连接的用户显示控制台消息。您可以使用环境文件中的以下参数向 /etc/issue 添加横幅文本。考虑自定义此示例文本以满足您的要求。

resource_registry:
  OS::TripleO::Services::Sshd:
    /usr/share/openstack-tripleo-heat-templates/deployment/sshd/sshd-baremetal-puppet.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.yaml

维护所有审计事件的记录可帮助您建立系统基准、进行故障排除或分析导致特定结果的事件序列。审计系统能够记录许多类型的事件，如对系统时间的更改、对 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  : 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

您还可以添加限制访问的规则。规则定义期间使用的数字将决定规则的优先级。例如，Rabx 的规则号默认为 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 定义中提取端口要求。例如，Rabx 的规则存储在 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:
      /usr/share/openstack-tripleo-heat-templates/deployment/aide/aide-baremetal-ansible.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)的根访问权限。此行为由 /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 已采用云审计数据联邦(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

DEBUG 参数的默认值为 False。在生产环境中保留默认值。仅在调查过程中更改此设置。当您将 DEBUG 参数的值更改为 True 时，Djjan 可将 stack straces 输出到包含敏感 Web 服务器状态信息的浏览器用户。

当 DEBUG 参数的值为 True 时，ALLOWED_HOSTS 设置也会被禁用。有关配置 ALLOWED_HOSTS 的更多信息，请参阅配置 ALLOWED_HOSTS。

最佳实践是将 Dashboard 服务(horizon)部署到第二个级别域，而不是任何级别的共享域。以下提供了每个示例：

根据浏览器的 相同 策略，将控制面板服务部署到专用的第二个域，将 Cookie 和安全令牌与其他域隔离。在子域上部署时，仪表板服务的安全性等同于在同一第二个域中部署的最小安全应用程序。

您可以通过避免 Cookie 支持的会话存储并配置 HTTP Strict Transport Security (HSTS) （本指南中的描述）来进一步缓解这个风险。

Horizon 基于 python Django Web 框架构建，这需要防止与误导 HTTP 主机标头关联的安全威胁。若要应用这种保护，请将 ALLOWED_HOSTS 设置配置为使用 OpenStack 仪表板提供的 FQDN。

当您配置 ALLOWED_HOSTS 设置时，任何带有与此列表中值不匹配的 Host 标头的 HTTP 请求都会被拒绝，并引发错误。

OpenStack 控制面板接受大多数字段中设置的整个 Unicode 字符。恶意的参与者可能会尝试使用这个可扩展性来测试跨站点脚本(XSS)漏洞。OpenStack Dashboard 服务(horizon)具有针对 XSS vulnerabilites 强化的工具。确保在自定义仪表板中正确使用这些工具非常重要。当您对自定义仪表板执行审计时，请注意以下几点：

使用多个 JavaScript 实例的仪表板应该针对不当使用 @csrf_exempt decorator 等漏洞进行审核。在降低 CORS (Cross Origin Resource Sharing)限制前，评估所有不遵循推荐的安全设置的仪表板。将您的 Web 服务器配置为发送限制性 CORS 标头，其中包含每个响应。只允许仪表板域和协议，例如：Access-Control-Allow-Origin: https://example.com/。您不应该允许通配符来源。

DISALLOW_IFRAME_EMBED 设置不允许仪表板嵌入到 iframe 中。旧浏览器仍容易受到跨脚本(XFS)漏洞的影响，因此此选项为不需要基准的部署添加额外的安全强化。默认设置为 True，但在需要时可使用环境文件禁用它。

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false

建议您使用 HTTPS 来加密仪表板流量。您可以将它配置为使用可识别证书颁发机构(CA)中的有效可信证书来完成此操作。只有在所有用户浏览器中预安装信任的根目录时，私有机构发布的证书才适合。

配置 HTTP 请求到仪表板域，以重定向到完全限定的 HTTPS URL。

如需更多信息，请参阅使用 Ansible 实施 TLS-e

HTTP 严格传输安全性(HSTS)可防止浏览器在最初进行安全连接后进行后续的不安全连接。如果您已在公共或不可信区上部署了 HTTP 服务，则 HSTS 特别重要。

对于基于 director 的部署，此设置在 /usr/share/openstack-tripleo-heat-templates/deployment/horizon-container-puppet.yaml 文件中默认启用：

horizon::enable_secure_proxy_ssl_header: true

不建议在仪表板中使用前端缓存工具，因为它呈现直接从 OpenStack API 请求生成的动态内容。因此，前端缓存层（如 varnish ）可以防止显示正确的内容。控制面板使用 Django，它直接从 Web 服务提供静态介质，并且已经受益于 Web 主机缓存。

对于基于 director 的部署，horizon 的默认会话后端是 django.contrib.sessions.backends.backends.cache，它与 memcached 相结合。出于性能的原因，此方法优先于本地内存缓存，对于高可用性和负载平衡安装而言是安全的，并且能够在多个服务器上共享缓存，同时仍将其视为单个缓存。

您可以在 director 的 horizon.yaml 文件中查看这些设置：

          horizon::cache_backend: django.core.cache.backends.memcached.MemcachedCache
          horizon::django_session_engine: 'django.contrib.sessions.backends.cache'

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

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

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

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

仪表板的默认配置使用 django_compressor 在提供前压缩和减去 CSS 和 JavaScript 内容。这个过程应该在部署仪表板前静态完成，而不是使用默认的请求动态压缩，并将生成的文件以及部署的代码或 CDN 服务器复制到 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

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

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

    parameter_defaults:
      ControllerExtraConfig:
        horizon::disable_password_reveal: false

法规行业（如 HIPAA、PCI-DSS 和美国政府）要求您显示用户登录横幅。Red Hat OpenStack Platform (RHOSP)仪表板(horizon)使用默认的主题(RCUE)，它存储在 horizon 容器中。

在自定义 Dashboard 容器中，您可以通过手动编辑 /usr/share/openstack-dashboard/openstack_dashboard/themes/rcue/templates/auth/login.html 文件来创建登录横幅：

上面的例子生成类似如下的仪表板：

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

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

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

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

OpenStack 网络组件有：

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

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

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

建议您将此流量划分为不同的区。如需更多信息，请参阅下一部分。

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

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

在设计 OpenStack 网络基础架构的初始架构阶段，务必要确保提供适当的经验，以帮助设计第 1 个物理网络基础架构，以识别正确的安全控制和审计机制。

OpenStack 网络添加了一层虚拟化网络服务，使项目能够设计自己的虚拟网络。目前，这些虚拟化服务不像它们的传统网络对应部分一样创新。在采用这些虚拟服务之前，请考虑这些虚拟服务的当前状态，因为它规定了在虚拟化和传统网络边界上实施哪些控制。

OpenStack 网络可以对每个项目/网络组合使用两种不同的机制进行流量分隔：VLAN (IEEE 802.1Q 标记)或使用 VXLAN 或 GRE 封装的 L2 隧道。OpenStack 部署的范围和扩展决定了您应该用于流量隔离或隔离的方法。

计算通过使用 OpenStack 网络服务支持项目网络流量访问控制。安全组允许管理员和项目指定允许通过虚拟接口端口传递的流量类型和方向（入口/出口）。安全组规则是有状态的 L2-L4 流量过滤器。

OpenStack 网络路由器可以连接多个 L2 网络，也可以提供一个网关，它将一个或多个私有 L2 网络连接到共享的外部网络，如可用于访问互联网的公共网络。

L3 路由器在将路由器连接到外部网络的网关端口上提供基本网络地址转换(SNAT 和 the)功能。此路由器 SNAT （源 NAT）默认所有出口流量，并支持浮动 IP，它从外部网络上的公共 IP 创建静态一对一的双向映射到附加到路由器的另一个子网上的私有 IP。浮动 IP （通过 DNAT）为实例提供外部入站连接，并可从一个实例移动到另一个实例。

考虑使用每个项目 L3 路由和浮动 IP 来更精细的项目实例连接。应向连接到公共网络的实例或使用浮动 IP 指定特殊考虑。建议您使用仔细考虑的安全组过滤对需要外部公开的服务的访问。

默认情况下，服务质量(QoS)策略和规则由云管理员管理，这会导致项目无法创建特定的 QoS 规则，或者将 pecific 策略附加到端口。在某些情况下，如某些电信应用程序，管理员可能会信任项目，从而使他们创建并将自己的策略附加到端口。这可以通过修改 policy.json 文件来实现。

从 Red Hat OpenStack Platform 12，neutron 支持入口和出口流量的带宽限制 QoS 规则。这个 QoS 规则名为 QosBandwidthLimitRule，它接受每秒以 KB 为单位计算的两个非负整数：

QoSBandwidthLimitRule 已在 neutron Open vSwitch、Linux 网桥和 SR-IOV 驱动程序中实施。但是，对于 SR-IOV 驱动程序，不使用 max-burst-kbps 值，如果设置，则会被忽略。

对于所有离开一个虚拟机的网络流量，QoS 规则 QosDscpMarkingRule 在服务的类型头（IPv4 (RFC 2474)）或网络类头（IPv6）中设置 DSCP（Differentiated Service Code Point ）值，相关的规则会在其中应用。这是一个 6 位标头，它带有 21 个有效值，它表示数据包的丢弃优先级，因为它跨网络满足拥塞。防火墙也可以使用它与其访问控制列表匹配有效或无效的流量。

OpenStack 负载均衡服务(octavia)为 Red Hat OpenStack Platform director 安装提供负载均衡服务(DSL)实现。为了实现负载平衡，octavia 支持启用多个供应商驱动程序。参考供应商驱动程序(Amphora 提供者驱动程序)是一个开源、可扩展和高可用性的负载平衡供应商。它通过管理一组虚拟机来实现负载平衡服务的交付，它可根据上面称为 amphorae-​ 来按需启动。

有关负载均衡服务的更多信息，请参阅 Using Octavia for Load Balancing-as-a-Service 指南。

本节讨论 OpenStack 网络配置最佳实践，因为它们应用到 OpenStack 部署中的项目网络安全性。

如果没有定义每个请求的最大正文大小，攻击者可以制作一个大大小的任意 OSAPI 请求，从而导致服务崩溃，最终会导致服务攻击。分配 t he maximum 值可确保任何恶意的请求被阻止，确保服务持续可用。

检查 cinder.conf 中的 [oslo_middleware] 部分下的 max_request_body_size 是否被设置为 114688。

未加密的卷数据会使卷托管平台特别用于攻击者的高值目标，因为它允许攻击者读取许多不同的虚拟机的数据。此外，物理存储介质可以被欺骗、重新挂载并从其他机器访问。加密卷数据和卷备份有助于降低这些风险，并为卷托管平台提供防御。块存储(cinder)可以在写入磁盘前加密卷数据，因此请考虑启用卷加密，并将 Barbican 用于私钥存储。

可以通过多种方式擦除块存储设备。传统方法是将 lvm_type 设置为 thin，然后使用 volume_clear 参数。或者，如果卷加密功能为 ed，如果卷加密密钥被删除，则不需要卷 wiping。

volume_clear 参数可以接受 zero 或 shred 作为参数。零 会将单个传递零写入设备。shred 操作将编写三个通过预先确定的位模式。

Manila 使用 keystone 注册，允许您使用 manila endpoint 命令找到 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 中的 tcp6，它支持 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 中指定模式。

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

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

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

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

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

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

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

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

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

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

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

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

创建共享网络后，manila 会检索由网络提供程序决定的网络信息：网络类型、分段标识符（如果网络使用分段）以及 CIDR 标记中的 IP 块，用于分配网络。

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

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

创建共享并获取其导出位置后，用户没有挂载它并使用文件操作的权限。用户需要明确授予新共享的访问权限。

客户端身份验证和授权(authN/authZ)可与安全服务一起执行。如果共享驱动程序和后端支持，manila 可以使用 LDAP、Kerberos 或 Microsoft Active 目录。

安全服务 是一个 manila 实体，提取一组选项，用于为特定共享文件系统协议定义安全区，如 Active Directory 域或 Kerberos 域。安全服务包含 manila 创建加入给定域的服务器所需的所有信息。

通过使用 API，用户可以创建、更新、查看和删除安全服务。安全服务基于以下假设设计：

在创建安全服务时，您可以选择以下身份验证服务之一：

Manila 允许您使用以下选项配置安全服务：

现有安全服务实体可以与共享网络实体关联，通知 manila 关于一组共享的安全性和网络配置。您还可以查看指定共享网络的所有安全服务列表，并将它们与共享网络解除关联。

作为共享所有者的管理员和用户可以通过 IP 地址、用户、组或 TLS 证书创建使用身份验证的访问规则来管理对共享的访问规则。身份验证方法取决于您配置和使用的共享驱动程序和安全服务。然后，您可以将后端配置为使用特定的身份验证服务，该服务可以在没有 manila 和 keystone 的情况下操作客户端。

支持某个驱动程序的特定身份验证服务并不意味着可以使用任何共享文件系统协议进行配置。支持的共享文件系统协议有 NFS、CEPHFS、CIFS、GlusterFS 和 HDFS。有关特定驱动程序及其安全服务的配置的详情，请查看驱动程序厂商的文档。

有些驱动支持安全服务，而其他驱动则不支持上述任何安全服务。例如，带有 NFS 或 CIFS 共享文件系统协议的通用驱动程序仅支持通过 IP 地址进行身份验证方法。

生产 manila 部署的建议配置是使用 CIFS 共享协议创建共享，并将其添加到 Microsoft Active Directory 目录服务中。使用这个配置，您将获得集中数据库和集成 Kerberos 和 LDAP 方法的服务。

用户可以指定哪些特定客户端有权访问他们所创建的共享。由于 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 参数应当由 share 驱动程序设置为 0.0.0.0/0，这意味着任何主机都会被拒绝。

使用 manila，您可以通过指定其中一个支持的共享访问级别来授予或拒绝对共享的访问访问权限：

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

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

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

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

默认情况下，共享类型创建为 public。在创建共享类型时，使用 --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 协议在存储服务节点之间复制数据。另外，代理服务在客户端端点和云环境之间转发数据时与存储服务通信。

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

下图演示了一种可能的网络架构，将 Object Storage 网络架构与管理节点(OSAM)搭配使用：

建议您将 swift 配置为以非 root (UID 0)服务帐户下运行。一个建议是，director 部署的用户名 swift 并带有一个主组 swift。对象存储服务包括 proxy-server、container-server、account-server。

/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 组中的成员资格。

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

swift 帐户不是用户帐户或凭证。存在以下区别：

在每个级别上，您都有控制用户的 ACL； ACL 会根据所使用的身份验证系统进行解释。最常见的身份验证提供程序是 Identity Service (keystone)；自定义身份验证提供程序也可用。

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

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 ( https://swift.cloud.example.org:44443/v1/AUTH_8980 的代理节点或负载均衡器的 URL)获得响应。

如果无法使用 Apache 选项，或者您希望卸载 TLS 工作的性能，您可以使用专用的网络设备负载均衡器。这是使用多个代理节点时提供冗余和负载平衡的常见方法。

如果您选择卸载 TLS，请确保负载均衡器和代理节点之间的网络链接位于私有(V) LAN 段上，以便网络中的其他节点（可能会被入侵）无法对未加密的流量进行线(sniff)。如果发生此类漏洞，攻击者可以获得对端点客户端或云管理员凭证的访问权限，并访问云数据。

您使用的身份验证服务将决定如何在对端点客户端的响应中配置不同的 URL，允许它们使用负载均衡器而不是单独的代理节点。

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

默认情况下，Object Storage 附带两个身份验证中间件模块，其中之一可用作开发自定义身份验证中间件的示例代码。

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

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

如需更多信息，请参阅 Barbican 集成指南： https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/16.2/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 服务有权访问属于项目的数据和元数据，或引用项目信息。例如，存储在 OpenStack 云中的项目数据可能包括以下项目：

由 OpenStack 云存储的元数据包括以下项目（此列表不可更改）：

最佳实践建议，Operator 在机构控制前，或发布前必须清理云系统介质（数字和非数字），或发布前再发布以进行重复使用。根据特定安全域和敏感度，清理方法应实施适当的强度和完整性。

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 部署需要解决以下实践（其它操作）：

强烈建议使用 OpenStack 卷加密功能。这在卷加密下的 Data Encryption 部分中讨论。使用此功能时，通过安全地删除加密密钥来实现数据销毁。最终用户可以在创建卷时选择此功能，但请注意，管理员必须首先执行对卷加密功能的一次性设置。

如果没有使用 OpenStack 卷加密功能，则其他方法通常很难启用。如果使用后端插件，则可能会独立进行加密或非标准覆盖解决方案。OpenStack Block Storage 的插件以各种方式存储数据。许多插件都特定于某个供应商或技术，而其他插件则针对文件系统（如 LVM 或 ZFS）提供更多 合并解决方案。安全销毁数据的方法因插件、供应商和文件系统而异。

有些后端（如 ZFS）支持写时复制以防止数据暴露。在这些情况下，从未写入块读取始终返回零。其他后端（如 LVM）可能无法原生支持此功能，因此 cinder 插件在将之前写入的块分配给用户前需要覆盖之前写入的块。务必要检查您选择的卷后端所提供的保证，并查看哪些补救可能可用于提供这些保证。

镜像服务具有延迟删除功能，它将假定在定义的时间段内删除镜像。如果此行为是安全问题，请考虑禁用此功能；您可以通过编辑 glance-api.conf 文件并将 delayed_delete 选项设置为 False 来完成此操作。

计算具有软删除功能，它允许在定义的时间段内删除的实例处于软删除状态。这个实例可以在此时间段内恢复。要禁用 soft-delete 功能，请编辑 /var/lib/config-data/puppet-generated/nova_libvirt/etc/nova/nova.conf 文件，并将 reclaim_instance_interval 选项留空。

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

在部署服务器时，可能无法始终具有可靠的方法将其与攻击者的服务器区分开。这个功能可能依赖于硬件/BMC 到某种程度，但通常看似没有可验证在服务器中内置的方式。

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

代表项目加密数据的重要性主要与攻击者可以访问项目数据的供应商认为风险非常相关。此处可能有一些要求，以及每个政策的要求、私有合同，甚至当涉及公有云供应商的私有合同的情况下也是如此。在选择项目加密策略前，请考虑获取风险评估和法律建议。

每个实例或每个对象加密是首选进行的、按降序、每个项目、每个主机和每个云聚合的。本建议与实施的复杂性和困难有关。目前，对于某些项目，实施加密非常困难或根本不可能。实施者应该优先考虑加密项目数据。

通常，数据加密与可靠地销毁项目和每个实例数据的能力相关，只需抛出密钥。请注意，为此，最好以可靠和安全的方式销毁这些密钥。

提供加密用户数据的机会：

为了解决项目数据隐私的常见关注，OpenStack 社区中值得关注来使数据加密更加严格。在将数据保存到云之前，最终用户很难加密其数据，这是项目对象（如介质文件、数据库存档等）的可行路径。在某些情况下，客户端加密用于加密由需要客户端交互（如显示密钥）保存的数据，以解密数据以供以后使用。

barbican 有助于项目更无缝地加密数据，并使其可访问，而不会让用户承担密钥管理。作为 OpenStack 的一部分，提供加密和密钥管理服务可简化数据需求，并有助于解决客户对隐私或滥用数据的关注。

卷加密功能依赖于密钥管理服务，如密钥管理器服务(barbican)，用于创建和安全强化密钥存储。

熵指的是实例可用的随机数据的质量和来源。加密技术通常依赖于随机性，这需要从熵池中提取。当实例无法获得足够的熵来支持加密技术所需的随机性时，会发生熵不足。熵不足可以在实例中清单，因为看似无关。例如，引导时间缓慢可能是由等待 SSH 密钥生成的实例造成的。熵不足的可能性也可以使云用户使用来自实例内的质量熵源，从而确保云中运行的应用程序的安全性较低。

为需要足够硬件随机数生成器(HRNG)的实例提供高质量的熵来源来支持实例。对于日常操作，现代 HRNG 可以生成足够的熵来支持 50-100 Compute 节点。高带宽 HRNG 可以处理更多节点。您必须识别云的应用程序要求，以确保有足够的熵可用。

VirtIO RNG 是一个随机数字生成器，默认使用 /dev/urandom 作为熵的来源，以确保实例在引导时不会耗尽熵。也可以将其配置为使用 HRNG，或像熵收集守护进程(EGD)等工具，提供通过部署分发熵的方法。默认情况下，实例启用了 virtio RNG 设备。要为实例禁用 Virtio RNG 设备，您必须将 hw_rng:allowed 设置为实例类别上的 False。

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

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

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

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

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

OpenStack 文档提供了有关如何创建并将镜像上传到镜像服务的指导。另外，假设您有安装和强化客户机操作系统的过程。以下项目将提供有关如何将镜像传送到 OpenStack 的附加指导。获取镜像的各种选项。每种方法均有特定的步骤，可以帮助验证镜像的来源。

在本例中，RHEL 6 CCE-26976-1 帮助在 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 等自动系统进行镜像构建，或者配置管理实用程序（如 Dan 或 Puppet）进行强化，可让您生成一致的镜像，并跟踪基础镜像的合规性，以便随着时间的推移进行相应的强化指南。

如果订阅公有云服务，您应该与云供应商联系，以了解用于生成其默认镜像的流程概述。如果供应商允许您上传自己的镜像，则需要确保在使用它创建实例前验证您的镜像没有被修改。为此，请参阅 _Verification 镜像签名_ 的以下部分，或者无法使用以下段落。

Image Service (glance)用于将镜像上传到节点上的 Compute 服务。此传输应进一步通过 TLS 强化。镜像位于节点上后，它将通过基本的校验和进行检查，然后根据所启动实例的大小扩展其磁盘。如果稍后，同一镜像在这个节点上使用相同的实例大小启动，它将从相同的扩展镜像启动。由于这种扩展的镜像在启动前不会被重新验证，所以存在风险。用户不知道篡改，除非手动检查生成的镜像中文件。要帮助缓解这一点，请参阅以下有关验证镜像签名的主题。

您可以启用镜像签名验证，以确保您的镜像服务(glance)镜像在计算服务(nova)启动实例前不包含未授权的更改。启用此功能后，您可以防止新实例启动，其中可能包括恶意软件或安全漏洞。

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

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

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

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

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

管理程序运行独立的虚拟机。此管理程序可以在操作系统中运行，或者直接运行在硬件上（称为裸机）。对虚拟机监控程序的更新不会传播到虚拟机。例如，如果部署使用 KVM 并有一组 CentOS 虚拟机，对 KVM 的更新不会更新在 CentOS 虚拟机上运行的任何内容。

考虑将虚拟机的清晰所有权分配给所有者，然后负责虚拟机的强化、部署和继续功能。您还应计划定期部署更新，而首先在类似生产环境的环境中对其进行测试。

大多数常见操作系统都包括基于主机的防火墙，以实现额外的安全层。虽然实例应尽可能少运行（如果是单用途实例），但实例上运行的所有应用程序都应被设置，以确定应用程序需要访问哪些系统资源、运行所需的最低特权级别以及预期网络流量将进入和来自虚拟机的预期网络流量。此预期流量应当作为允许的流量添加到基于主机的防火墙中，以及任何必要的日志记录和管理通信，如 SSH 或 RDP。防火墙配置中应明确拒绝所有其他流量。

在 Linux 实例上，上面的应用程序配置集可与 audit2allow 等工具一起使用，以构建 SELinux 策略，进一步保护大多数 Linux 发行版上的敏感系统信息。SELinux 使用用户、策略和安全上下文的组合来比较应用程序运行所需的资源，并从不需要的其他系统资源中进行分段。

OpenStack 为主机和网络提供安全组，来向给定项目中的实例添加安全保护。它们和基于主机的防火墙类似，因为它们允许或拒绝基于端口、协议和地址的流量。但是，安全组规则仅应用于传入流量，而基于主机的防火墙规则可以同时应用到传入和传出流量。主机和网络安全组规则也可以冲突和拒绝合法流量。考虑为所使用的网络检查是否已正确配置了安全组。如需了解更多详细信息，请参阅本指南中的安全组。

默认情况下，可通过虚拟控制台远程访问实例的控制台。这对故障排除非常有用。Red Hat OpenStack Platform 使用 VNC 进行远程控制台访问。

如果需要 SSH 到实例，您可以将计算配置为在创建时自动将所需的 SSH 密钥注入实例。

如需更多信息，请参阅 创建镜像。

基于 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)是在互联网协议中进行身份验证和数据安全的框架。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。

本节介绍 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

本节介绍 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 中使用 SASL 指定使用 SASL 机制，方法是添加：

qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>

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

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

Linux 使用命名空间将进程分配到独立域中。本指南的其他部分更详细地涵盖系统比较。

OpenStack 提供面向公共的、内部管理员和私有 API 端点。默认情况下，OpenStack 组件使用公开的端点。建议将这些组件配置为使用正确的安全域中的 API 端点。内部管理端点允许进一步提升对 keystone 的访问，因此可能需要进一步隔离这一点。

服务根据 OpenStack 服务目录选择其对应的 API 端点。这些服务可能无法遵循列出的公共或内部 API 端点值。这可能导致内部管理流量路由到外部 API 端点。

Identity 服务目录应该了解您的内部 URL。虽然默认情况下不使用这个功能，但它可以通过配置获得。另外，当此行为成为默认值后，它应该与预期更改兼容。

考虑将配置的端点与网络级别隔离，只要它们具有不同的访问级别。Admin 端点旨在由云管理员访问，因为它提供了对内部或公共端点上不可用的 keystone 操作的提升访问权限。内部端点主要用于在云（如 OpenStack 服务）中使用内部端点，且通常无法在部署网络外部访问。公共端点应该启用 TLS，以及部署外唯一可访问用于云用户操作的 API 端点。

director 会自动注册端点的内部 URL。如需更多信息，请参阅 https://github.com/openstack/tripleo-heat-templates/blob/a7857d6dfcc875eb2bc611dd9334104c18fe8ac6/network/endpoints/build_endpoint_map.py。

您可以强制某些服务使用特定的 API 端点。因此，建议任何联系另一个服务的 API 的 OpenStack 服务都必须明确配置为访问正确的内部 API 端点。

每个项目可能会显示定义目标 API 端点的方法不一致。OpenStack 的未来发行版本可以通过一致使用 Identity 服务目录来解决这些不一致的情况。

OpenStack 中大多数 API 端点和其他 HTTP 服务都使用 Python Ppaste Deploy 库。从安全的角度来看，此库通过应用程序的配置启用对请求过滤器管道的操作。此链中的每个元素称为 中间件。更改管道中过滤器的顺序或添加额外的中间件可能会产生无法预计的安全问题。

通常，实施者会添加中间件来扩展 OpenStack 的基本功能。考虑在 HTTP 请求管道中添加非标准软件组件来仔细考虑引入的潜在暴露程度。

您可以隔离 API 端点进程以提高安全性。考虑在单独的主机上的公共安全域中部署 API 端点，以提高隔离。

如果在 overcloud 中启用了 SSL/TLS，请考虑强化与 HAProxy 配置一起使用的 SSL/TLS 密码和规则。通过强化 SSL/TLS 密码，您可以帮助避免 SSL/TLS 漏洞，如 POODLE 漏洞。

API 端点通常会跨越多个安全区，因此您必须特别注意 API 进程的分离。例如，在网络设计级别，您可以考虑限制对指定系统的访问。如需更多信息，请参阅有关安全区的指南。

通过小心建模，您可以使用网络 ACL 和 IDS 技术来强制实施网络服务之间的显式点到点通信。作为关键跨域服务，这种类型的显式实施也适用于 OpenStack 的消息队列服务。

要强制执行策略，您可以配置基于主机的服务、基于主机的防火墙（如 iptables）、本地策略(SELinux)以及可选的全局网络策略。

您应该将 API 端点进程相互隔离，以及计算机上的其他进程。这些进程的配置应受 Discretionary Access Controls (DAC)和强制访问控制(MAC)的限制。这些增强的访问控制的目标是帮助包含 API 端点安全破坏。

速率限制是控制基于网络的应用程序接收的事件频率的方法。如果没有强大的速率限制，可能会导致应用程序受到各种拒绝服务攻击的影响。对于 API，这尤其如此，其性质旨在接受类似请求类型和操作的高频率。

建议所有端点（特别是公共）都提供额外的保护层，例如使用物理网络设计、速率限制代理或 Web 应用程序防火墙。

在配置和实施任何速率限制功能时，Operator 会仔细规划并考虑 OpenStack 云中的用户和服务的独立性能需求。

对于 Red Hat OpenStack Platform 部署，所有服务都放在负载平衡代理后面。

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

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

Identity Provider (IdP)- 存储用户帐户的服务。在本例中，IdM 中保存的用户帐户使用 RH-SSO 呈现给 Keystone。

Service Provider (SP)- 需要从 IdP 中用户进行身份验证的服务。在这种情况下，keystone 是授予 IdM 用户的 Dashboard 访问权限的服务供应商。

在下图中，keystone (SP)与 RH-SSO (IdP)通信，它也能够充当其他 IdP 的通用适配器。在此配置中，您可以在 RH-SSO 上将 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/16.2/html-single/federate_with_identity_service/