安全和强化指南


Red Hat OpenStack Platform 17.0

最佳实践、合规性和安全强化

OpenStack Documentation Team

摘要

本指南提供有关强化 Red Hat OpenStack Platform 环境的安全性的良好实践建议和概念性信息。

第 1 章 安全性简介

使用 Red Hat Openstack Platform (RHOSP)提供的工具在规划和操作中优先考虑安全性,以满足用户对隐私性和数据安全性的期望。未能实施安全标准会导致停机或数据泄露。您的用例可能会受需要传递审计和合规性流程的法律。

注意

按照本指南中的说明来强化您的环境的安全性。但是,这些建议不能保证安全性或合规性。您必须根据环境的唯一要求评估安全性。

1.1. Red Hat OpenStack Platform 安全

默认情况下,Red Hat OpenStack Platform (RHOSP) director 使用以下工具和访问控制为安全创建 overcloud:

SElinux
SELinux 通过提供需要每个进程明确权限的访问控制来提供 RHOSP 安全增强。
Podman
Podman 作为容器工具是 RHOSP 的一个安全选项,因为它不使用客户端/服务器模型,要求具有 root 访问权限的进程正常工作。
系统访问限制
您只能使用 director 在 overcloud 部署期间为 tripleo-admin 创建的 SSH 密钥或 overcloud 上创建的 SSH 密钥登录 overcloud 节点。您不能使用 SSH 和密码登录 overcloud 节点,或者使用 root 登录 overcloud 节点。

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

  • 公共 TLS 和 TLS-everywhere
  • 硬件安全模块与 OpenStack Key Manager (barbican)集成
  • 签名的镜像和加密卷
  • 使用工作流执行对密码和 fernet 密钥进行轮转

1.2. 了解 Red Hat OpenStack Platform admin 角色

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

为用户授予 admin 角色的项目是执行 openstack 命令的默认项目。例如,如果一个 admin 用户在一个名为 development 的项目中运行以下命令,将会在名为 development 项目中创建一个名为 internal-network 的网络。

openstack network create internal-network
Copy to Clipboard Toggle word wrap

admin 用户可以通过使用-- project 参数在任意项目中创建 internal-network

openstack network create internal-network --project testing
Copy to Clipboard Toggle word wrap

1.3. 识别 Red Hat OpenStack Platform 中的安全区

安全区是共享常见安全问题的资源、应用、网络和服务器。设计安全区,以便具有常见的身份验证和授权要求和用户。您可以根据云的架构、环境中可接受的信任级别以及机构的标准化要求,自行定义自己的安全区(如需要精细的安全区)。区域及其信任要求可能会因云实例是公共、私有还是混合而异。

例如,您可以将 Red Hat OpenStack Platform 的默认安装划分为以下区:

Expand
表 1.1. 安全区
网络详情

公开

external

public 区域托管外部网络、公共 API 和浮动 IP 地址,以用于实例的外部连接。此区域允许从管理控制外的网络进行访问,是云基础架构的不受信任的区域。

Guest

tenant

guest 区域托管项目网络。对于允许不受限制地访问实例的公共云和私有云供应商,它不受信任的。

存储访问

storage, storage_mgmt

存储访问区域用于存储管理、监控和集群以及存储流量。

控制

ctlplane, internal_api, ipmi

control 区域还包括 undercloud、主机操作系统、服务器硬件、物理网络和 Red Hat OpenStack Platform director。

1.4. 在 Red Hat OpenStack Platform 中查找安全区

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

先决条件

  • 已安装 Red Hat OpenStack Platform 环境。
  • 以 stack 身份登录 director。

流程

  1. stackrc

    $ source /home/stack/stackrc
    Copy to Clipboard Toggle word wrap
  2. 运行 openstack subnet list,将分配的 ip 网络与其关联的区匹配:

    openstack subnet list -c Name -c Subnet
    +---------------------+------------------+
    | Name                | Subnet           |
    +---------------------+------------------+
    | ctlplane-subnet     | 192.168.101.0/24 |
    | storage_mgmt_subnet | 172.16.105.0/24  |
    | tenant_subnet       | 172.16.102.0/24  |
    | external_subnet     | 10.94.81.0/24    |
    | internal_api_subnet | 172.16.103.0/24  |
    | storage_subnet      | 172.16.104.0/24  |
    +---------------------+------------------+
    Copy to Clipboard Toggle word wrap
  3. 运行 openstack server list 以列出您基础架构中的物理服务器:

    openstack server list -c Name -c Networks
    +-------------------------+-------------------------+
    | Name                    | Networks                |
    +-------------------------+-------------------------+
    | overcloud-controller-0  | ctlplane=192.168.101.15 |
    | overcloud-controller-1  | ctlplane=192.168.101.19 |
    | overcloud-controller-2  | ctlplane=192.168.101.14 |
    | overcloud-novacompute-0 | ctlplane=192.168.101.18 |
    | overcloud-novacompute-2 | ctlplane=192.168.101.17 |
    | overcloud-novacompute-1 | ctlplane=192.168.101.11 |
    +-------------------------+-------------------------+
    Copy to Clipboard Toggle word wrap
  4. 使用 openstack server list 命令中的 ctlplane 地址查询物理节点的配置:

    ssh tripleo-admin@192.168.101.15 ip addr
    Copy to Clipboard Toggle word wrap

1.5. 连接安全区

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

在某些情况下,OpenStack 操作员可能希望将集成点的安全为比它所在的任何区域更高的标准。根据以上 API 端点示例,如果这些区域没有完全隔离,则可能会对公共区的公共 API 端点作为目标,利用这一范围。

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

1.6. 威胁缓解

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

  • 应用最小特权的原则。
  • 对内部和外部接口使用加密。
  • 使用集中式身份管理。
  • 保持 Red Hat OpenStack Platform 更新。

计算服务可以为恶意参与者提供 DDoS 和暴力攻击的工具。预防方法包括出口安全组、流量检查、入侵检测系统以及客户教育和认知。对于公共网络访问或可通过互联网访问公共网络(如互联网)访问的部署,请确保进程和基础架构能够检测和解决出站滥用。

第 2 章 安全增强

以下小节提供了强化 overcloud 安全性的一些建议。

2.1. 使用安全 root 用户访问

overcloud 镜像自动包含 root 用户的强化安全性。例如,每个部署的 overcloud 节点都会自动禁用对 root 用户的直接 SSH 访问。您仍然可以访问 overcloud 节点上的 root 用户。每个 overcloud 节点都有一个 tripleo-admin 用户帐户。此用户帐户包含 undercloud 公共 SSH 密钥,它无需从 undercloud 向 overcloud 节点提供 SSH 访问。

先决条件

  • 已安装 Red Hat OpenStack Platform director 环境。
  • 以 stack 身份登录 director。

流程

  1. 在 undercloud 节点上,以 tripleo-admin 用户身份通过 SSH 登录 overcloud 节点。
  2. 通过 sudo -i 切换到 root 用户。

2.2. 将服务添加到 overcloud 防火墙

部署 Red Hat OpenStack Platform 时,每个核心服务都会在每个 overcloud 节点上使用一组默认的防火墙规则进行部署。您可以使用 ExtraFirewallRules 参数创建规则来打开其他服务的端口,或者创建规则来限制服务。

每个规则名称都会成为相应 iptables 规则的注释。每个规则名称以三位前缀开头,以帮助 Puppet 在最终的 iptables 文件中对规则进行排序。默认 Red Hat OpenStack Platform 规则使用 000 中的前缀为 200 范围。为新服务创建规则时,请为名称添加大于 200 的三位数字前缀。

流程

  1. 使用字符串在 ExtraFireWallRules 参数下定义每个规则名称。您可以使用规则名称下的以下参数来定义规则:

    • dport :与规则关联的目的地端口。
    • Proto:: 与规则关联的协议。默认为 tcp
    • action:: 与规则关联的操作策略。默认为 accept
    • Source:: 与规则关联的源 IP 地址。

      以下示例演示了如何使用规则为自定义应用程序打开其他端口:

      cat > ~/templates/firewall.yaml <<EOF
      parameter_defaults:
        ExtraFirewallRules:
          '300 allow custom application 1':
            dport: 999
            proto: udp
          '301 allow custom application 2':
            dport: 8081
            proto: tcp
      EOF
      Copy to Clipboard Toggle word wrap
      注意

      如果没有设置 action 参数,则结果将 接受。您只能将 action 参数设置为 drop,insert, 或 append

  2. openstack overcloud deloy 命令中包含 ~/templates/firewall.yaml 文件。包括部署所需的所有模板:

    openstack overcloud deploy --templates /
    ...
    -e /home/stack/templates/firewall.yaml /
    ....
    Copy to Clipboard Toggle word wrap

2.3. 从 overcloud 防火墙中删除服务

您可以使用规则来限制服务。您在规则名称中使用的数字决定了将插入规则的 iptables 中的位置。以下步骤演示了如何将 rabbitmq 服务限制为 InternalAPI 网络。

流程

  1. 在 Controller 节点上,查找 rabbitmq 的默认 iptables 规则数量:

    [tripleo-admin@overcloud-controller-2 ~]$ sudo iptables -L | grep rabbitmq
    ACCEPT     tcp  --  anywhere             anywhere             multiport dports vtr-emulator,epmd,amqp,25672,25673:25683 state NEW /* 109 rabbitmq-bundle ipv4 */
    Copy to Clipboard Toggle word wrap
  2. 在环境文件 uder parameter_defaults 中,使用 ExtraFirewallRules 参数将 rabbitmq 限制到 InternalApi 网络。该规则的编号低于默认的 rabbitmq 规则编号或 109 :

    cat > ~/templates/firewall.yaml <<EOF
    parameter_defaults:
      ExtraFirewallRules:
        '098 allow rabbit from internalapi network':
          dport:
          - 4369
          - 5672
          - 25672
          proto: tcp
          source: 10.0.0.0/24
        '099 drop other rabbit access':
          dport:
          - 4369
          - 5672
          - 25672
          proto: tcp
          action: drop
    EOF
    Copy to Clipboard Toggle word wrap
    注意

    如果没有设置 action 参数,则结果将 接受。您只能将 action 参数设置为 drop,insert, 或 append

  3. openstack overcloud deloy 命令中包含 ~/templates/firewall.yaml 文件。包括部署所需的所有模板:

    openstack overcloud deploy --templates /
    ...
    -e /home/stack/templates/firewall.yaml /
    ....
    Copy to Clipboard Toggle word wrap

2.4. 更改简单网络管理协议(SNMP)字符串

director 为您的 overcloud 提供默认的只读 SNMP 配置。建议更改 SNMP 字符串,以降低未授权用户了解您的网络设备的风险。

注意

当使用字符串参数配置 ExtraConfig 接口时,您必须使用以下语法来确保 heat 和 Hiera 不将字符串解释为布尔值: '"<VALUE>"'

使用 overcloud 的环境文件中的 ExtraConfig hook 设置以下 hieradata:

SNMP 传统访问控制设置

snmp::ro_community
IPv4 只读 SNMP 社区字符串.默认值为 public
snmp::ro_community6
IPv6 只读 SNMP 社区字符串。默认值为 public
snmp::ro_network
允许 RO 查询 守护进程的网络。这个值可以是字符串或数组。默认值为 127.0.0.1
snmp::ro_network6
允许 RO 查询 带有 IPv6 的守护进程的网络。这个值可以是字符串或数组。默认值为 ::1/128
tripleo::profile::base::snmp::snmpd_config
要作为安全 valve 添加到 snmpd.conf 文件中的行数组。默认值为 []。有关所有可用选项,请参阅 SNMP Configuration File 网页。

例如:

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring
Copy to Clipboard Toggle word wrap

这会改变所有节点上的只读 SNMP 社区字符串。

基于 SNMP 视图的访问控制设置(VACM)

snmp::com2sec
一个 VACM com2sec 映射的数组。必须提供 SECNAME、SOURCE 和 COMMUNITY。
snmp::com2sec6
一个 VACM com2sec6 映射的数组。必须提供 SECNAME、SOURCE 和 COMMUNITY。

例如:

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: ["notConfigUser default mysecurestring"]
    snmp::com2sec6: ["notConfigUser default myv6securestring"]
Copy to Clipboard Toggle word wrap

这会改变所有节点上的只读 SNMP 社区字符串。

如需更多信息,请参阅 snmpd.conf 手册页。

2.5. 使用 Open vSwitch 防火墙

您可以将安全组配置为使用 Red Hat OpenStack Platform director 中的 Open vSwitch (OVS)防火墙驱动程序。使用 NeutronOVSFirewallDriver 参数指定您要使用的防火墙驱动程序:

  • iptables_hybrid - 配置网络服务(neutron)以使用基于 iptables/hybrid 的实现。
  • openvswitch - 配置网络服务,以使用基于 OVS 防火墙流的驱动程序。

openvswitch 防火墙驱动程序包含更高的性能,并减少了用于将客户机连接到项目网络的接口和网桥数量。

重要

与 iptables 防火墙驱动程序相比,Open vSwitch (OVS)防火墙驱动程序处理多播流量会有所不同。使用 iptables 时,VRRP 流量被拒绝,您必须在安全组规则中启用 VRRP,以便任何 VRRP 流量到达端点。使用 OVS 时,所有端口共享相同的 OpenFlow 上下文,并且每个端口无法单独处理多播流量。由于安全组不适用于所有端口(例如,路由器上的端口),因此 OVS 使用 NORMAL 操作,并将多播流量转发到 RFC 4541 指定的所有端口。

注意

iptables_hybrid 选项与 OVS-DPDK 不兼容。openvswitch 选项与 OVS Hardware Offload 不兼容。

network-environment.yaml 文件中配置 NeutronOVSFirewallDriver 参数:

NeutronOVSFirewallDriver: openvswitch
Copy to Clipboard Toggle word wrap
  • NeutronOVSFirewallDriver :配置要在实施安全组时使用的防火墙驱动程序的名称。可能的值取决于您的系统配置。某些示例包括 noopopenvswitchiptables_hybrid。空字符串的默认值会产生支持的配置。

第 3 章 记录您的 RHOSP 环境

在识别安全问题、攻击向量和可能的安全区桥接点时,记录系统组件、网络、服务和软件非常重要。Red Hat OpenStack Platform (RHOSP)部署的文档应包括以下信息:

  • RHOSP 生产环境中的系统组件、网络、服务和软件的描述。
  • 任何临时资源(如虚拟机或虚拟磁盘卷)的清单。

3.1. 记录系统角色

Red Hat OpenStack Platform (RHOSP)部署中的每个节点都服务于特定角色,可以为云的基础架构或提供云资源贡献。

贡献基础架构的节点运行云相关的服务,如消息排队服务、存储管理、监控、网络,以及支持云操作和调配所需的其他服务。基础架构角色示例包括:

  • Controller
  • Networker
  • 数据库
  • Telemetry

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

  • CephStorage
  • Compute
  • ComputeOvsDpdk
  • ObjectStorage

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

流程

  1. 检查您的部署的现有模板,以查找用于指定当前正在使用的角色的文件。在您的环境中使用的每个角色都有一个 NIC 配置文件。在以下示例中,RHOSP 环境包括 ComputeHCI 角色、Compute 角色和 Controller 角色:

    $ cd ~/templates
    $ tree
    .
    ├── environments
    │   └── network-environment.yaml
    ├── hci.yaml
    ├── network
    │   └── config
    │       └── multiple-nics
    │           ├── computehci.yaml
    │           ├── compute.yaml
    │           └── controller.yaml
    ├── network_data.yaml
    ├── plan-environment.yaml
    └── roles_data_hci.yaml
    Copy to Clipboard Toggle word wrap
  2. RHOSP 环境的每个角色执行许多相互相关的服务。您可以通过检查 roles 文件来记录各个角色使用的服务。

    1. 如果为您的模板生成了一个 roles 文件,您可以在 ~/templates 目录中找到该文件:

      $ cd ~/templates
      $ find . -name *role*
      > ./templates/roles_data_hci.yaml
      Copy to Clipboard Toggle word wrap
    2. 如果没有为您的模板生成 roles 文件,您可以为当前用于检查文档的角色生成一个角色:

      $ openstack overcloud roles generate \
      > --roles-path /usr/share/openstack-tripleo-heat-templates/roles \
      > -o roles_data.yaml Controller Compute
      Copy to Clipboard Toggle word wrap

3.2. 创建硬件清单

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

先决条件

  • 已安装 Red Hat OpenStack Platform director 环境。
  • 您已为 Red Hat OpenStack Platform 部署内省节点。
  • 以 stack 身份登录 director。

流程

  1. 从 undercloud 中,提供 stackrc 文件:

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. 列出环境中的节点:

    $ openstack baremetal node list -c Name
    +--------------+
    | Name         |
    +--------------+
    | controller-0 |
    | controller-1 |
    | controller-2 |
    | compute-0    |
    | compute-1    |
    | compute-2    |
    +--------------+
    Copy to Clipboard Toggle word wrap
  3. 对于从其收集信息的每个裸机节点,并运行以下命令来检索内省数据:

    $ openstack baremetal introspection data save <node> | jq
    Copy to Clipboard Toggle word wrap

    <node > 替换为在第 1 步中检索的列表中的节点名称。

  4. 可选: 要将输出限制为特定类型的硬件,您可以检索清单密钥列表并查看特定密钥的内省数据:

    1. 运行以下命令,从内省数据获取顶层密钥列表:

      $ openstack baremetal introspection data save controller-0 | jq '.inventory | keys'
      
      [
        "bmc_address",
        "bmc_v6address",
        "boot",
        "cpu",
        "disks",
        "hostname",
        "interfaces",
        "memory",
        "system_vendor"
      ]
      Copy to Clipboard Toggle word wrap
    2. 选择一个键,如 disks,并运行以下命令以获取更多信息:

      $ openstack baremetal introspection data save controller-1 | jq '.inventory.disks'
      [
        {
          "name": "/dev/sda",
          "model": "QEMU HARDDISK",
          "size": 85899345920,
          "rotational": true,
          "wwn": null,
          "serial": "QM00001",
          "vendor": "ATA",
          "wwn_with_extension": null,
          "wwn_vendor_extension": null,
          "hctl": "0:0:0:0",
          "by_path": "/dev/disk/by-path/pci-0000:00:01.1-ata-1"
        }
      ]
      Copy to Clipboard Toggle word wrap

3.3. 创建软件清单

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

  • 已安装 Red Hat OpenStack Platform 环境。
  • 以 stack 身份登录 director。

流程

  1. 确定您知道可能受到恶意活动影响的系统和服务的入口点。在 undercloud 上运行以下命令:

    $ cat /etc/hosts
    $ source stackrc ; openstack endpoint list
    $ source overcloudrc ; openstack endpoint list
    Copy to Clipboard Toggle word wrap
  2. RHOSP 部署到容器化服务中,因此您可以通过检查该节点上运行的容器来查看 overcloud 节点上的软件组件。使用 ssh 连接到 overcloud 节点并列出正在运行的容器。例如,若要查看 compute-0 上的 overcloud 服务,请运行类似如下的命令:

    $ ssh tripleo-admin@compute-0 podman ps
    Copy to Clipboard Toggle word wrap

第 4 章 身份和访问管理

Identity 服务(keystone)为 Red Hat OpenStack Platform 环境中的云用户提供身份验证和授权。您可以使用 Identity 服务进行直接最终用户身份验证,或者将其配置为使用外部验证方法来满足安全要求或与您当前的身份验证基础架构匹配。

4.1. Red Hat OpenStack Platform fernet 令牌

Fernet 是替换 UUID 令牌提供程序的默认令牌提供程序。默认情况下,每个 fernet 令牌保持有效最多一小时。这允许用户执行一系列任务,而无需重新验证。

身份验证后,Identity 服务(keystone):

  • 发出加密的 bearer 令牌,称为 fernet 令牌。此令牌代表您的身份。
  • 授权您根据角色执行操作。

4.2. OpenStack Identity 服务实体

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

用户
OpenStack Identity 服务(keystone)用户是身份验证的原子单元。用户必须分配项目的角色才能进行身份验证。
OpenStack Identity 服务组是用户的逻辑分组。组可以提供对特定角色下项目的访问权限。管理组而不是用户可简化角色的管理。
角色
OpenStack Identity 服务角色定义 OpenStack API,这些 API 可供分配了这些角色的用户或组访问。
项目
OpenStack Identity 服务项目是有共同访问物理资源共享配额的用户组,以及从这些物理资源构建的虚拟基础架构。
Domains
OpenStack Identity 服务域是项目、用户和组的高级安全界限。您可以使用 OpenStack 身份域来集中管理所有基于 keystone 的身份组件。Red Hat OpenStack Platform 支持多种域。您可以使用单独的身份验证后端代表不同域的用户。

4.3. 使用 keystone 进行身份验证

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

部署 Red Hat OpenStack Platform (RHOSP)时,可以指定密码要求比为服务生成的默认密码更复杂。发生这种情况时,服务无法进行身份验证,部署会失败。

您最初必须部署 RHOSP,而无需密码复杂性要求。部署完成后,将 KeystonePasswordRegex 参数添加到您的模板中,然后重新运行部署。

要强化您的环境,请实施满足您机构标准的密码复杂性要求。有关 NIST 建议密码复杂性要求的详情,请参考 发布 88-63B,附录 A

Expand
表 4.1. Identity 服务身份验证参数

参数

描述

KeystoneChangePasswordUponFirstUse

启用此选项要求用户在创建用户时或管理重置时更改密码。

KeystoneDisableUserAccountDaysInactive

在被视为"主动"并自动禁用(锁定)前,用户可以经过验证的最大天数。

KeystoneLockoutDuration

超过用户帐户的失败尝试次数上限(如 KeystoneLockoutFailureAttempts指定)的最大数量时,将锁定用户帐户数。

KeystoneLockoutFailureAttempts

KeystoneLockoutDuration 指定的秒数内,用户可以在用户帐户锁定前验证的次数上限。

KeystoneMinimumPasswordAge

在用户可以更改密码之前必须使用密码的天数。这可防止用户立即更改密码,以擦除密码历史记录并重复使用旧密码。

KeystonePasswordExpiresDays

在要求用户更改密码之前,密码被视为有效的天数。

KeystonePasswordRegex

用于验证密码强度要求的正则表达式。

KeystonePasswordRegexDescription

以人员使用的语言描述您的密码正则表达式。

KeystoneUniqueLastPasswordCount

这将控制在历史记录中保留的之前用户密码迭代的数量,以便强制新创建的密码是唯一的。

重复失败的登录尝试可能是尝试进行暴力攻击的签名。在重复登录尝试失败后,您可以使用 Identity Service 限制对帐户的访问。

先决条件

  • 已安装 Red Hat OpenStack Platform director 环境。
  • 以 stack 身份登录 director。

流程

  1. 要配置用户可以在用户帐户锁定前验证的次数上限,请在环境文件中设置 KeystoneLockoutFailureAttemptsKeystoneLockoutDuration heat 参数的值。在以下示例中,KeystoneLockoutDuration 设置为 1 小时:

    parameter_defaults
        KeystoneLockoutDuration: 3600
        KeystoneLockoutFailureAttempts: 3
    Copy to Clipboard Toggle word wrap
  2. 在部署脚本中包含 环境文件。当您在之前部署的环境中运行部署脚本时,会使用附加参数进行更新:

    openstack overcloud deploy --templates \
    ...
    -e keystone_config.yaml
    ...
    Copy to Clipboard Toggle word wrap

4.4. 使用外部身份提供程序进行身份验证

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

当您使用单独的 IdP 时,外部身份验证凭据与其它 OpenStack 服务使用的数据库分开。这种分离会降低存储凭证破坏的风险。

每个外部 IdP 都有一个一对一的映射到 OpenStack Identity 服务(keystone)域。您可以将多个现有域与红帽 OpenStack 平台共存。

外部身份验证提供了一种方式,可以在不创建额外的身份的情况下使用现有凭证访问 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.4.1. LDAP 集成的工作方式

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

Red Hat OpenStack Platform 由多个网络和端点组成,它们处理您可以保护的敏感或机密数据。使用传输层安全(TLS)时,您可以使用对称密钥加密保护流量。密钥和证书在 TLS 握手中协商,这需要在称为证书颁发机构(CA)的中间通过共享信任来验证服务器的身份。

公钥基础架构(PKI)是一种框架,用于通过证书颁发机构验证实体。

5.1. 公钥基础架构组件(PKI)

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

Expand
表 5.1. 主要术语
术语定义

结束实体

使用数字证书验证自己的用户、进程或系统。

证书颁发机构(CA)

CA 是最终实体信任的实体,以及验证最终实体的依赖方。

依赖方

依赖方收到数字证书作为最终实体的验证,并能够验证数字证书。

数字证书

签名的公钥证书具有可验证的实体和公钥,并由 CA 发布。当 CA 为证书签名时,它会从使用其私钥加密的证书创建信息摘要。您可以使用与 CA 关联的公钥验证签名。X.509 标准用于定义证书。

注册机构(RA)

RA 是可选的专用授权,可以在 CA 发布证书之前执行管理功能,如验证最终实体。如果没有 RA,CA 会验证最终实体。

证书撤销列表(CRL)

CRL 是已撤销的证书序列号列表。显示已撤销序列号的证书的最终实体在 PKI 模型中不被信任。

CRL issuer

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

证书存储库

存储和查询最终实体证书和证书撤销列表的位置。

5.2. 证书颁发机构要求和建议

您必须获取由广泛认可的证书颁发机构(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

注意

这将仅在公开访问的端点上配置带有 SSL/TLS 的 Red Hat OpenStack Platform。

5.3. 识别环境中的 TLS 版本

重要

Red Hat OpenStack 平台已弃用 TLS 版本 1.0。另外,对于 NIST 批准,必须至少使用 TLS 1.2。如需更多信息,请参阅 选择、配置和使用传输层安全(TLS)实施指南

您可以使用 cipherscan 来决定部署所呈现的 TLS 版本。Cipherscan 可以从 https://github.com/mozilla/cipherscan 克隆。这个示例输出演示了从 horizon 接收的结果:

注意

从非生产环境的系统运行 cipherscan,因为在第一次运行时可能会安装额外的依赖项。

流程

  • 针对 Dashboard 服务可访问的 URL 运行密码扫描:

    $ ./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
    Copy to Clipboard Toggle word wrap

在扫描服务器时,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
Copy to Clipboard Toggle word wrap

在这个输出中,TLS 1.0TLS 1.1 的不容限被报告为 PRESENT,这意味着无法建立连接,并且 Cipherscan 在广告支持时无法连接。因此,最好在扫描的服务器上不启用协议的那些(以及较低版本)的协议。

5.4. OpenStack 的身份管理(IdM)服务器建议

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

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

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

Expand
表 5.2. 参数建议
选项建议

--admin-password

请注意您提供的值。在配置 Red Hat OpenStack Platform 以使用 IdM 时,您将需要此密码。

--ip-address

请注意您提供的值。undercloud 和 overcloud 节点需要网络访问此 ip 地址。

--setup-dns

使用这个选项在 IdM 服务器上安装集成的 DNS 服务。undercloud 和 overcloud 节点使用 IdM 服务器进行域名解析。

--auto-forwarders

使用这个选项使用 /etc/resolv.conf 中的地址作为 DNS 转发器。

--auto-reverse

使用这个选项解析 IdM 服务器 IP 地址的反向记录和区域。如果反向记录或区域都无法解析,IdM 会创建反向区域。这简化了 IdM 部署。

--ntp-server, --ntp-pool

您可以使用这些选项或其中任一个来配置 NTP 源。IdM 服务器和 OpenStack 环境必须具有正确的和同步时间。

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

5.5. 使用 Ansible 实施 TLS-e

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

先决条件

  • 确保完成 undercloud 的所有配置步骤,如创建 stack 用户。如需了解更多详细信息,请参阅 Director 安装和使用 以了解更多详细信息
  • DNS 服务器的 IP 地址在 undercloud 上配置为 IdM 服务器的 IP 地址。undercloud.conf 文件中必须配置以下参数之一:

    • DEFAULT/undercloud_nameservers
    • %SUBNET_SECTION%/dns_nameservers

流程

使用以下步骤在 Red Hat OpenStack Platform 的新安装或您要使用 TLS-e 配置的现有部署上实施 TLS-e。如果您在预置备的节点上部署使用 TLS-e 的 Red Hat OpenStack Platform,则必须使用此方法。

注意

如果您要为现有环境实施 TLS-e,则需要运行 openstack undercloud installopenstack overcloud deploy 等命令。这些过程是幂等的,仅调整您现有的部署配置,以匹配更新的模板和配置文件。

  1. 配置 /etc/resolv.conf 文件:

    /etc/resolv.conf 中设置适当的搜索域和 undercloud 名称服务器。例如,如果部署域是 example.com,而 FreeIPA 服务器的域是 bigcorp.com,则将以下行添加到 /etc/resolv.conf 中:

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
    Copy to Clipboard Toggle word wrap
  2. 安装所需的软件:

    sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
    Copy to Clipboard Toggle word wrap
  3. 使用特定于您的环境的值导出环境变量。

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER 
    1
    
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD 
    2
    
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com 
    3
    
    export USER=stack
    export CLOUD_DOMAIN=example.com
    Copy to Clipboard Toggle word wrap
    1 2
    IdM 用户凭证是一个管理用户,可以添加新的主机和服务。
    3
    UNDERCLOUD_FQDN 参数的值与 /etc/hosts 中的第一个主机名到 IP 地址映射匹配。
  4. 在 undercloud 上运行 undercloud-ipa-install.yaml ansible playbook:

    ansible-playbook \
    --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
    /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
    Copy to Clipboard Toggle word wrap
  5. 在 undercloud.conf 中添加以下参数

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
    Copy to Clipboard Toggle word wrap
  6. [可选] 如果您的 IPA 域与您的 IPA 域不匹配,请设置 certmonger_krb_realm 参数的值:

    1. /home/stack/hiera_override.yaml 中设置 certmonger_krb_realm 的值:

      parameter_defaults:
        certmonger_krb_realm = EXAMPLE.COMPANY.COM
      Copy to Clipboard Toggle word wrap
    2. undercloud.conf 中的 custom_env_files 参数的值设置为 /home/stack/hiera_override.yaml

      custom_env_files = /home/stack/hiera_override.yaml
      Copy to Clipboard Toggle word wrap
  7. 部署 undercloud:

    openstack undercloud install
    Copy to Clipboard Toggle word wrap

验证

通过完成以下步骤验证 undercloud 是否已正确注册:

  1. 列出 IdM 中的主机:

    $ kinit admin
    $ ipa host-find
    Copy to Clipboard Toggle word wrap
  2. 确认 undercloud 上是否存在 /etc/novajoin/krb5.keytab

    ls /etc/novajoin/krb5.keytab
    Copy to Clipboard Toggle word wrap
注意

novajoin 目录名称仅用于传统的命名目的。

在 overcloud 上配置 TLS-e

当您使用 TLS (TLS-e)部署 overcloud 时,来自 Undercloud 和 Overcloud 的 IP 地址将自动注册到 IdM。

  1. 在部署 overcloud 之前,创建一个 YAML 文件 tls-parameters.yaml,其内容类似于以下内容:您选择的值将特定于您的环境:

    parameter_defaults:
        DnsSearchDomains: ["example.com"]
        CloudDomain: example.com
        CloudName: overcloud.example.com
        CloudNameInternal: overcloud.internalapi.example.com
        CloudNameStorage: overcloud.storage.example.com
        CloudNameStorageManagement: overcloud.storagemgmt.example.com
        CloudNameCtlplane: overcloud.ctlplane.example.com
        IdMServer: freeipa-0.redhat.local
        IdMDomain: redhat.local
        IdMInstallClientPackages: False
    
    resource_registry:
          OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
    Copy to Clipboard Toggle word wrap
    • 显示的 OS::TripleO::Services::IpaClient 参数的值覆盖 enable-internal-tls.yaml 文件中的默认设置。您必须在 openstack overcloud deploy 命令中确保 tls-parameters.yaml 文件遵循 enable-internal-tls.yaml
    • 有关实现 TLS-e 的参数的更多信息,请参阅 tripleo-ipa 的参数
  2. 部署 overcloud。您需要在部署命令中包含 tls-parameters.yaml :

    DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
    CUSTOM_TEMPLATES=/home/stack/templates
    
    openstack overcloud deploy \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
    -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
    ...
    Copy to Clipboard Toggle word wrap
  3. 通过查询 keystone 以获取端点列表来确认每个端点正在使用 HTTPS:

    openstack endpoint list
    Copy to Clipboard Toggle word wrap

5.6. tripleo-ipa 的参数

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

  • CloudDomain: example.com
  • cloudName: overcloud.example.com
  • CloudNameCtlplane: overcloud.ctlplane.example.com
  • CloudNameInternal: overcloud.internalapi.example.com
  • CloudNameStorage: overcloud.storage.example.com
  • CloudNameStorageManagement: overcloud.storagemgmt.example.com

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

CertmongerKerberosRealm
CertmongerKerberosRealm 参数设置为 IPA 域的值。如果 IPA 域与 IPA 域不匹配,则需要此项。
DnsSearchDomains
DnsSearchDomains 参数是一个用逗号分开的列表。如果 IdM 服务器的域与云域不同,请在 DnsSearchDomains 参数中包含 IdM 服务器的域。
EnableEtcdInternalTLS
如果您在分布式计算节点(DCN)架构上部署 TLSe,您必须添加 EnableEtcdInternalTLS 参数,其值为 True
IDMInstallClientPackages
如果您预置备了计算节点,请将 IDMInstallClientPackages 参数设置为 True。否则,将值设置为 False
IDMModifyDNS
IDMModifyDNS 参数设置为 false,以禁用 Red Hat Identity Server 上 overcloud 节点的自动 IP 注册。
IdmDomain
IdmDomain 参数设置为红帽身份服务器的 FQDN 的域部分。您指定的值也用作 IdM 域的值。如果 IdM 域和 IdM 域不同,请使用 CertmongerKerberosRealm 参数明确设置域。
IdmServer
IdmServer 参数设置为红帽身份服务器的 FQDN。如果您使用复制的 IdM 环境,则使用以逗号分隔的列表设置多个值。有关 IdM 副本的更多信息,请参阅安装 IdM 副本

5.7. 在 TLS 下加密 memcached 流量(TLS-e)

重要

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

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

  1. 创建名为 memcached.yaml 的环境文件,其中包含以下内容,以添加 memcached 的 TLS 支持:

    parameter_defaults:
        MemcachedTLS: true
        MemcachedPort: 11212
    Copy to Clipboard Toggle word wrap
  2. 在 overcloud 部署过程中包含 memcached.yaml 环境文件:

    openstack overcloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml \
    -e /home/stack/memcached.yaml
    ...
    Copy to Clipboard Toggle word wrap

其它资源

5.8. 增加私钥的大小

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

  • 使用 CertificateKeySize 参数来全局更改私钥大小。
  • 使用特定于服务的参数,如 RedisCertificateKeySize、修改特定私钥,或者覆盖全局 CertificateKeySize 参数。

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

在以下示例中,私钥的全局值为 4096redis 的私钥是 2048,因为 RedisCertificateKeySize 会覆盖全局参数:

Example

parameter_defaults:
    CertificateKeySize: '4096'
    RedisCertificateKeySize: '2048'
Copy to Clipboard Toggle word wrap

当您将现有 IPA 服务器替换为其副本时,您必须更新必要的参数。如果不这样做,在更新集群的配置时会导致 overcloud 部署失败。

流程

  1. 在每个 overcloud 节点上,编辑 /etc/ipa/default.conf 配置文件,以确保 serverxmlrpc_uri 参数包含 IdM 服务器的完全限定域名(FQDN):

    #File modified by ipa-client-install
    
    [global]
    basedn = dc=redhat,dc=local
    realm = REDHAT.LOCAL
    domain = redhat.local
    server = freeipa-0.redhat.local
    host = undercloud-0.redhat.local
    xmlrpc_uri = https://freeipa-0.redhat.local/ipa/xml
    enable_ra = True
    Copy to Clipboard Toggle word wrap
  2. 在 undercloud 上,编辑 /home/stack/templates/tls-parameters.yaml 环境文件,并确保 IPA_SERVER_HOSTNAME 参数与 /etc/ipa/default.conf 中的 xmlrpc_uri 和 server 参数中显示的 FQDN 匹配。确保所有参数都与您的环境匹配:

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com
    export USER=stack
    export CLOUD_DOMAIN=example.com
    Copy to Clipboard Toggle word wrap

第 6 章 配置自定义 SSL/TLS 证书

您可以手动将 undercloud 配置为使用 SSL/TLS 进行公共端点上的通信。使用 SSL/TLS 手动配置 undercloud 端点时,您要创建安全端点作为概念验证。红帽建议使用证书颁发机构解决方案。

当您使用证书颁发机构(CA)解决方案时,您已有生产环境的准备解决方案,如证书续订、证书撤销列表(CRL)和行业接受加密。有关使用 Red Hat Identity Manager (IdM)作为 CA 的信息,请参阅使用 Ansible 实施 TLS-e

如果要将 SSL 证书与您自己的证书颁发机构一起使用,您必须完成以下配置步骤。

6.1. 初始化签名主机

签名主机是使用证书颁发机构生成并签名新证书的主机。如果您从未在所选签名主机上创建 SSL 证书,您可能需要初始化该主机,让它能够为新证书签名。

流程

  1. /etc/pki/CA/index.txt 文件包含所有签名证书的记录。请确定文件系统路径和 index.txt 文件已存在:

    $ sudo mkdir -p /etc/pki/CA
    $ sudo touch /etc/pki/CA/index.txt
    Copy to Clipboard Toggle word wrap
  2. /etc/pki/CA/serial 文件标识下一个序列号,以用于下一个要签名的证书。检查是否存在此文件。如果此文件不存在,则使用新启动值创建新文件:

    $ echo '1000' | sudo tee /etc/pki/CA/serial
    Copy to Clipboard Toggle word wrap

6.2. 创建证书颁发机构

一般情况下,您需要使用一个外部的证书认证机构来签发您的 SSL/TLS 证书。在某些情况下,您可能想使用自己的证书颁发机构。例如,您可能想拥有仅限内部使用的证书颁发机构。

流程

  1. 生成密钥和证书对以充当证书颁发机构:

    $ openssl genrsa -out ca.key.pem 4096
    $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
    Copy to Clipboard Toggle word wrap
  2. openssl req 命令会要求输入认证机构的详细信息。根据提示输入相关信息。这些命令创建一个称为 ca.crt.pem 的证书颁发机构文件。
  3. enable-tls.yaml 文件中,将证书位置设置为 PublicTLSCAFile 参数的值。当您将证书位置设置为 PublicTLSCAFile 参数的值时,请确保将 CA 证书路径添加到 clouds.yaml 身份验证文件中。

    parameter_defaults:
        PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem
    Copy to Clipboard Toggle word wrap

6.3. 将此证书颁发机构添加到客户端

对于旨在使用 SSL/TLS 通信的所有外部客户端,将证书颁发机构文件复制到需要访问 Red Hat OpenStack Platform 环境的每个客户端。

流程

  1. 将证书颁发机构复制到客户端系统:

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
    Copy to Clipboard Toggle word wrap
  2. 将证书颁发机构文件复制到每个客户端后,在每个客户端上运行以下命令,将证书添加到证书颁发机构信任捆绑包中:

    $ sudo update-ca-trust extract
    Copy to Clipboard Toggle word wrap

6.4. 创建 SSL/TLS 密钥

在 OpenStack 环境中启用 SSL/TLS 需要一个 SSL/TLS 密钥来生成证书。

流程

  1. 运行以下命令以生成 SSL/TLS 密钥 (server.key.pem):

    $ openssl genrsa -out server.key.pem 2048
    Copy to Clipboard Toggle word wrap

6.5. 创建 SSL/TLS 证书签名请求

完成以下步骤以创建证书签名请求。

流程

  1. 复制默认 OpenSSL 配置文件:

    $ cp /etc/pki/tls/openssl.cnf .
    Copy to Clipboard Toggle word wrap
  2. 编辑新的 openssl.cnf 文件并配置要用于 director 的 SSL 参数。一个要修改的参数类型的示例包括:

    [req]
    distinguished_name = req_distinguished_name
    req_extensions = v3_req
    
    [req_distinguished_name]
    countryName = Country Name (2 letter code)
    countryName_default = AU
    stateOrProvinceName = State or Province Name (full name)
    stateOrProvinceName_default = Queensland
    localityName = Locality Name (eg, city)
    localityName_default = Brisbane
    organizationalUnitName = Organizational Unit Name (eg, section)
    organizationalUnitName_default = Red Hat
    commonName = Common Name
    commonName_default = 192.168.0.1
    commonName_max = 64
    
    [ v3_req ]
    # Extensions to add to a certificate request
    basicConstraints = CA:FALSE
    keyUsage = nonRepudiation, digitalSignature, keyEncipherment
    subjectAltName = @alt_names
    
    [alt_names]
    IP.1 = 192.168.0.1
    DNS.1 = instack.localdomain
    DNS.2 = vip.localdomain
    DNS.3 = 192.168.0.1
    Copy to Clipboard Toggle word wrap

    commonName_default 设置为以下条目之一:

    • 如果使用 IP 地址通过 SSL/TLS 访问 director,则使用 undercloud.conf 文件中的 undercloud_public_host 参数。
    • 如果使用完全限定域名通过 SSL/TLS 访问 director,则使用此域名。

    编辑 alt_names 部分,使其包含以下条目:

    • IP - 客户端用于通过 SSL 访问 director 的 IP 地址列表。
    • DNS - 客户端用于通过 SSL 访问 director 的域名列表。其中也包含公共 API IP 地址作为在 alt_names 部分末尾的 DNS 条目。
    注意

    有关 openssl.cnf 的更多信息,请运行 man openssl.cnf 命令。

  3. 运行以下命令以生成证书签名请求 (server.csr.pem):

    $ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
    Copy to Clipboard Toggle word wrap

    确保使用 -key 选项包括 OpenStack SSL/TLS 密钥。

此命令生成 server.csr.pem 文件,这是证书签名请求。使用此文件创建 OpenStack SSL/TLS 证书。

6.6. 创建 SSL/TLS 证书

要为 OpenStack 环境生成 SSL/TLS 证书,必须存在以下文件:

openssl.cnf
指定 v3 扩展的自定义配置文件。
server.csr.pem
生成证书并使用 CA 对证书进行签名的证书签名请求。
ca.crt.pem
对证书进行签名的证书颁发机构。
ca.key.pem
证书颁发机构私钥。

流程

  1. 如果尚未存在,请创建 newcerts 目录:

    sudo mkdir -p /etc/pki/CA/newcerts
    Copy to Clipboard Toggle word wrap
  2. 运行以下命令,为 undercloud 或 overcloud 创建证书:

    $ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem
    Copy to Clipboard Toggle word wrap

    这个命令使用以下选项:

    -config
    使用一个自定义配置文件,它是带有 v3 扩展的 openssl.cnf 文件。
    -extensions v3_req
    已启用的 v3 扩展。
    -days
    定义证书到期前的天数。
    -in
    证书签名请求。
    -out
    生成的签名证书。
    -cert
    证书颁发机构文件。
    -keyfile
    证书颁发机构私钥。

此命令创建名为 server.crt.pem 的新证书。将此证书与 OpenStack SSL/TLS 密钥一起使用

6.7. 将证书添加到 undercloud

完成以下步骤,将 OpenStack SSL/TLS 证书添加到 undercloud 信任捆绑包中。

流程

  1. 运行以下命令以组合证书和密钥:

    $ cat server.crt.pem server.key.pem > undercloud.pem
    Copy to Clipboard Toggle word wrap

    此命令创建 undercloud.pem 文件。

  2. undercloud.pem 文件复制到 /etc/pki 目录内的位置,并设置必要的 SELinux 上下文,以便 HAProxy 能够读取:

    $ sudo mkdir /etc/pki/undercloud-certs
    $ sudo cp ~/undercloud.pem /etc/pki/undercloud-certs/.
    $ sudo semanage fcontext -a -t etc_t "/etc/pki/undercloud-certs(/.*)?"
    $ sudo restorecon -R /etc/pki/undercloud-certs
    Copy to Clipboard Toggle word wrap
  3. undercloud.pem 文件位置添加到 undercloud.conf 文件的 undercloud_service_certificate 选项中:

    undercloud_service_certificate = /etc/pki/undercloud-certs/undercloud.pem
    Copy to Clipboard Toggle word wrap

    不要设置或启用 generate_service_certificatecertificate_generation_ca 参数。director 使用这些参数自动生成证书,而不使用您手动创建的 undercloud.pem 证书。

  4. 将签名证书的证书颁发机构添加到 undercloud 的可信证书颁发机构列表中,以便 undercloud 内的不同服务能够访问证书颁发机构:

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
    $ sudo update-ca-trust extract
    Copy to Clipboard Toggle word wrap

    要验证证书颁发机构是否已添加到 undercloud,请使用 openssl 检查信任捆绑包:

    $ openssl crl2pkcs7 -nocrl -certfile /etc/pki/tls/certs/ca-bundle.crt | openssl pkcs7 -print_certs -text | grep <CN of the CA issuer> -A 10 -B 10
    Copy to Clipboard Toggle word wrap

    <CN of the CA issuer> 替换为 CA 颁发者的通用名称。此命令输出主要证书详细信息,包括有效期日期。

第 7 章 在 overcloud 公共端点中启用 SSL/TLS

默认情况下,overcloud 将未加密的端点用于 overcloud 服务。要在 overcloud 中启用 SSL/TLS,红帽建议您使用证书颁发机构(CA)解决方案。

使用 CA 解决方案时,您已有生产就绪的解决方案,如证书续订、证书吊销列表(CRL)和行业接受的加密。有关使用 Red Hat Identity Manager (IdM)作为 CA 的信息,请参阅使用 Ansible 实施 TLS-e

您可以使用以下手动过程为公共 API 端点启用 SSL/TLS,内部和管理 API 保持未加密状态。如果不使用 CA,还必须手动更新 SSL/TLS 证书。如需更多信息,请参阅 手动更新 SSL/TLS 证书

先决条件

  • 网络隔离,以定义公共 API 的端点。
  • 已安装 openssl-perl 软件包。
  • 您有一个 SSL/TLS 证书。如需更多信息,请参阅 配置自定义 SSL/TLS 证书

7.1. 启用 SSL/TLS

要在 overcloud 中启用 SSL/TLS,您必须创建一个环境文件,其中包含 SSL/TLS 证书和私钥的参数。

流程

  1. 从 heat 模板集合中复制 enable-tls.yaml 环境文件:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap
  2. 编辑此文件并为这些参数进行以下更改:

    SSLCertificate

    将证书文件(server.crt.pem)的内容复制到 SSLCertificate 参数中:

    parameter_defaults:
      SSLCertificate: |
        -----BEGIN CERTIFICATE-----
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
        ...
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
        -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    重要

    证书内容为所有新行需要相同的缩进级别。

    SSLIntermediateCertificate

    如果您有中间证书,请将中间证书的内容复制到 SSLIntermediateCertificate 参数中:

    parameter_defaults:
      SSLIntermediateCertificate: |
        -----BEGIN CERTIFICATE-----
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
        ...
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
        -----END CERTIFICATE-----
    Copy to Clipboard Toggle word wrap
    重要

    证书内容为所有新行需要相同的缩进级别。

    SSLKey

    将私钥(server.key.pem)的内容复制到 SSLKey 参数中:

    parameter_defaults:
      ...
      SSLKey: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
        ...
        ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
        -----END RSA PRIVATE KEY-----
    Copy to Clipboard Toggle word wrap
    重要

    私钥内容为所有新行需要相同的缩进级别。

7.2. 注入 root 证书

如果证书签名者不在 overcloud 镜像上的默认信任存储中,您必须将证书颁发机构注入 overcloud 镜像。

流程

  1. 从 heat 模板集合中复制 inject-trust-anchor-hiera.yaml 环境文件:

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.
    Copy to Clipboard Toggle word wrap

编辑此文件并为这些参数进行以下更改:

CAMap

列出要注入 overcloud 的每个证书颁发机构内容(CA)。overcloud 需要 CA 文件,用于为 undercloud 和 overcloud 签署证书。将 root 证书颁发机构文件(ca.crt.pem)的内容复制到条目。例如,您的 CAMap 参数可能类似如下:

parameter_defaults:
  CAMap:
    ...
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCS
        BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBw
        UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBA
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDBzCCAe+gAwIBAgIJAIc75A7FD++DMA0GCS
        BAMMD3d3dy5leGFtcGxlLmNvbTAeFw0xOTAxMz
        Um54yGCARyp3LpkxvyfMXX1DokpS1uKi7s6CkF
        -----END CERTIFICATE-----
Copy to Clipboard Toggle word wrap
重要

证书颁发机构内容为所有新行需要相同的缩进级别。

您还可以使用 CAMap 参数注入其他 CA。

7.3. 配置 DNS 端点

如果您使用 DNS 主机名通过 SSL/TLS 访问 overcloud,请将 /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 文件复制到 /home/stack/templates 目录中。

注意

如果初始部署中不包含此环境文件,则无法使用 TLS-everywhere 架构重新部署。

为所有字段配置主机和域名,根据需要为自定义网络配置参数:

CloudDomain
主机的 DNS 域。
CloudName
overcloud 端点的 DNS 主机名。
CloudNameCtlplane
provisioning 网络端点的 DNS 名称。
CloudNameInternal
内部 API 端点的 DNS 名称。
CloudNameStorage
存储端点的 DNS 名称。
CloudNameStorageManagement
存储管理端点的 DNS 名称。

流程

  • 使用以下参数之一添加要使用的 DNS 服务器:

    • DEFAULT/undercloud_nameservers
    • %SUBNET_SECTION%/dns_nameservers

7.4. 在 overcloud 创建过程中添加环境文件

将 use -e 选项与部署命令 openstack overcloud deploy 用于在部署过程中包含环境文件。按照以下顺序添加此部分中的环境文件:

  • 启用 SSL/TLS 的环境文件(enable-tls.yaml)
  • 设置 DNS 主机名的环境文件(custom-domain.yaml)
  • 注入 root 证书颁发机构的环境文件(inject-trust-anchor-hiera.yaml)
  • 设置公共端点映射的环境文件:

    • 如果您使用 DNS 名称访问公共端点,请使用 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
    • 如果您使用 IP 地址访问公共端点,请使用 /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml

流程

  • 使用以下部署命令片断作为如何包含 SSL/TLS 环境文件的示例:
$ openstack overcloud deploy --templates \
[...]
-e /home/stack/templates/enable-tls.yaml \
-e ~/templates/custom-domain.yaml \
-e ~/templates/inject-trust-anchor-hiera.yaml \
-e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
Copy to Clipboard Toggle word wrap

7.5. 手动更新 SSL/TLS 证书

如果您使用自己的 SSL/TLS 证书,这些证书不是随处 TLS 自动生成的(TLS-e)过程。

流程

  1. 使用以下内容编辑 heat 模板:

    • 编辑 enable-tls.yaml 文件,并更新 SSLCertificateSSLKeySSLIntermediateCertificate 参数。
    • 如果您的证书颁发机构已更改,请编辑 inject-trust-anchor-hiera.yaml 文件并更新 CAMap 参数。
  2. 重新运行部署命令:

    $ openstack overcloud deploy --templates \
    [...]
    -e /home/stack/templates/enable-tls.yaml \
    -e ~/templates/custom-domain.yaml \
    -e ~/templates/inject-trust-anchor-hiera.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml
    Copy to Clipboard Toggle word wrap
  3. 在 director 上,为每个 Controller 运行以下命令:

    ssh tripleo-admin@<controller> sudo podman \
    restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')
    Copy to Clipboard Toggle word wrap

Fernet 是默认的令牌提供程序,它取代 uuid。您可以查看 Fernet 部署并轮转 Fernet 密钥。Fernet 使用三种类型的密钥,它们存储在 /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys 中。最高数字目录包含主密钥,它生成新的令牌并解密现有的令牌。

Fernet 密钥轮转使用以下过程:

  1. 主密钥成为辅助密钥。
  2. <system> 签发一个新的主密钥。轮转除的主密钥将不再有效。您可以使用辅助密钥解密与之前的主密钥关联的令牌,但您无法发布新的令牌。

当您决定 Fernet 密钥轮转周期的长度时,遵循您的组织的安全状况。如果您的组织没有指导,因为安全考虑,每月轮转周期是很好的做法。

8.1. 检查 Fernet 部署

要测试 Fernet 令牌是否正常工作,请检索 Controller 节点的 IP 地址,SSH 到 Controller 节点,然后检查令牌驱动程序和提供程序的设置。

流程

  1. 检索 Controller 节点的 IP 地址:

    [stack@director ~]$ source ~/stackrc
    [stack@director ~]$ openstack server list
    --------------------------------------------------------------------------------------------+
    | ID                                   | Name                    | Status | Networks            |
    --------------------------------------------------------------------------------------------+
    | 756fbd73-e47b-46e6-959c-e24d7fb71328 | overcloud-controller-0  | ACTIVE | ctlplane=192.0.2.16 |
    | 62b869df-1203-4d58-8e45-fac6cd4cfbee | overcloud-novacompute-0 | ACTIVE | ctlplane=192.0.2.8  |
    --------------------------------------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap
  2. SSH 到 Controller 节点:

    [tripleo-admin@overcloud-controller-0 ~]$ ssh tripleo-admin@192.0.2.16
    Copy to Clipboard Toggle word wrap
  3. 检索令牌驱动程序和提供程序设置的值:

    [tripleo-admin@overcloud-controller-0 ~]$ sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf token driver
    sql
    [tripleo-admin@overcloud-controller-0 ~]$ sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf token provider
    fernet
    Copy to Clipboard Toggle word wrap
  4. 测试 Fernet 供应商:

    [tripleo-admin@overcloud-controller-0 ~]$ exit
    [stack@director ~]$ source ~/overcloudrc
    [stack@director ~]$ openstack token issue
    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | Field | Value |
    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    | expires | 2016-09-20 05:26:17+00:00 |
    | id | gAAAAABX4LppE8vaiFZ992eah2i3edpO1aDFxlKZq6a_RJzxUx56QVKORrmW0-oZK3-Xuu2wcnpYq_eek2SGLz250eLpZOzxKBR0GsoMfxJU8mEFF8NzfLNcbuS-iz7SV-N1re3XEywSDG90JcgwjQfXW-8jtCm-n3LL5IaZexAYIw059T_-cd8 |
    | project_id | 26156621d0d54fc39bf3adb98e63b63d |
    | user_id | 397daf32cadd490a8f3ac23a626ac06c |
    -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap

    结果包括长的 Fernet 令牌。

8.2. 使用工作流服务轮转 Fernet 密钥

为确保在堆栈更新后保持 Fernet 密钥,请使用 Workflow 服务(mistral)轮转密钥。默认情况下,director 使用 ManageKeystoneFernetKeys 参数在环境文件中管理 overcloud Fernet 密钥。Fernet 密钥存储在工作流服务中,KeystoneFernetKeys 部分中。

流程

  1. 查看现有的 Fernet 密钥:

    1. 确定 Fernet 密钥位置。以 tripleo-admin 用户身份登录 Controller 节点,并使用 crudini 命令查询 Fernet 密钥:

      [stack@<undercloud_host> ~]$ ssh tripleo-admin@overcloud-controller-o
      [tripleo-admin@overcloud-controller-0 ~]$ sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf fernet_tokens key_repository
      /etc/keystone/fernet-keys
      Copy to Clipboard Toggle word wrap
      注意

      /etc/keystone/ 目录引用容器文件系统路径。

    2. 检查当前的 Fernet 密钥目录:

      [tripleo-admin@overcloud-controller-0 ~]$ sudo ls /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys
      0  1  2
      Copy to Clipboard Toggle word wrap
      • 0 - 包括 staged 密钥,它会变为下一个主密钥,并始终为 0
      • 1 - 包含辅助密钥。
      • 2 - 包含主密钥。每次密钥轮转时,这个数字都会递增。最高数字始终用作主密钥。

        注意
        • 使用 max_active_keys 属性设置最大键数。默认值为 5 密钥。
        • 密钥在所有 Controller 节点上传播。
  2. 使用 workflow 命令轮转 Fernet 密钥:

    [stack@director ~]$ source ~/stackrc
    [stack@director ~]$ openstack workflow execution create tripleo.fernet_keys.v1.rotate_fernet_keys {"container": "overcloud"}
    --------------------------------------------------------------+
    | Field             | Value                                     |
    --------------------------------------------------------------+
    | ID                | 58c9c664-b966-4f82-b368-af5ed8de5b47      |
    | Workflow ID       | 78f0990a-3d34-4bf2-a127-10c149bb275c      |
    | Workflow name     | tripleo.fernet_keys.v1.rotate_fernet_keys |
    | Description       |                                           |
    | Task Execution ID | <none>                                    |
    | State             | RUNNING                                   |
    | State info        | None                                      |
    | Created at        | 2017-12-20 11:13:50                       |
    | Updated at        | 2017-12-20 11:13:50                       |
    --------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap

验证

  1. 检索 ID,并确保工作流成功。

    [stack@director ~]$ openstack workflow execution show 58c9c664-b966-4f82-b368-af5ed8de5b47
    --------------------------------------------------------------+
    | Field             | Value                                     |
    --------------------------------------------------------------+
    | ID                | 58c9c664-b966-4f82-b368-af5ed8de5b47      |
    | Workflow ID       | 78f0990a-3d34-4bf2-a127-10c149bb275c      |
    | Workflow name     | tripleo.fernet_keys.v1.rotate_fernet_keys |
    | Description       |                                           |
    | Task Execution ID | <none>                                    |
    | State             | SUCCESS                                   |
    | State info        | None                                      |
    | Created at        | 2017-12-20 11:13:50                       |
    | Updated at        | 2017-12-20 11:15:00                       |
    --------------------------------------------------------------+
    Copy to Clipboard Toggle word wrap
  2. 在 Controller 节点上,检查 Fernet 密钥的数量,并与前面的结果进行比较。

    [tripleo-admin@overcloud-controller-0 ~]$ sudo ls /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys
    0  1  2  3
    Copy to Clipboard Toggle word wrap
    • 0 - 包括 staged 密钥,始终为 0。这个密钥在下次轮转过程中成为主密钥。
    • 1 和 2 - 包含辅助密钥。
    • 3 - 包含主密钥。每次密钥轮转时,这个数字会递增。最高数字始终用作主密钥。

      注意
      • 使用 max_active_keys 属性设置最大键数。默认值为 5 密钥。
      • 密钥在所有 Controller 节点上传播。
重要

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

联邦信息处理标准(FIPS)是由国家标准与技术研究院(NIST)开发的一系列安全要求。在 Red Hat Enterprise Linux 9 中,支持的标准是 FIPS 出版物 140-3: Cryptographic 模块的安全要求。有关支持的标准的详情,请查看 联邦信息处理标准 140-3

这些安全要求定义了可接受的加密算法以及这些加密算法的使用,包括安全模块。

  • FIPS 140-3 验证只能通过 FIPS 批准的加密算法实现,其方式规定过,并通过经过验证的模块实现。
  • FIPS 140-3 兼容性只能通过 FIPS 批准的加密算法来实现。

Red Hat OpenStack Platform 17 是 FIPS 140-3 兼容。您可以使用红帽提供的镜像来部署 overcloud,利用 FIPS 兼容性。

注意

OpenStack 17.1 基于 Red Hat Enterprise Linux (RHEL) 9.2。RHEL 9.2 尚未提交用于 FIPS 验证。红帽计划获取 RHEL 9.0 和 RHEL 9.2 以及以后的 RHEL 9.x 偶数的次版本模块的 FIPS 验证,但没有具体的时间表。更新将包括在 Compliance Activities and Government Standards 中。

9.1. 启用 FIPS

启用 FIPS 时,您必须在安装 undercloud 和 overcloud 的过程中完成一系列步骤。

先决条件

  • 已安装 Red Hat Enterprise Linux,并已准备好开始安装 Red Hat OpenStack Platform director。

流程

  1. 在 undercloud 上启用 FIPS:

    1. 在您要在其上安装 undercloud 的系统中启用 FIPS:

      fips-mode-setup --enable
      Copy to Clipboard Toggle word wrap
      注意

      此步骤会将 fips=1 内核参数添加到 GRUB 配置文件中。因此,只有 Red Hat Enterprise Linux 使用的加密算法模块处于 FIPS 模式,且只使用标准批准的加密算法。

    2. 重启系统:
    3. 验证是否启用了 FIPS:

      fips-mode-setup --check
      Copy to Clipboard Toggle word wrap
    4. 安装和配置 Red Hat OpenStack Platform director。有关更多信息,请参阅: 在 undercloud 上安装 director
  2. 为 overcloud 准备启用了 FIPS 的镜像。

    1. 为 overcloud 安装镜像:

      sudo dnf -y install rhosp-director-images-uefi-fips-x86_64
      Copy to Clipboard Toggle word wrap
    2. stack 用户的主目录中创建 images 目录:

      $ mkdir /home/stack/images
      $ cd /home/stack/images
      Copy to Clipboard Toggle word wrap
    3. 将镜像提取到您的主目录中:

      for i in /usr/share/rhosp-director-images/*fips*.tar; do tar -xvf $i; done
      Copy to Clipboard Toggle word wrap
    4. 在上传镜像前,您必须创建符号链接:

      ln -s ironic-python-agent-fips.initramfs       ironic-python-agent.initramfs
      ln -s ironic-python-agent-fips.kernel          ironic-python-agent.kernel
      ln -s overcloud-hardened-uefi-full-fips.qcow2  overcloud-hardened-uefi-full.qcow2
      Copy to Clipboard Toggle word wrap
    5. 将启用了 FIPS 的 overcloud 镜像上传到镜像服务:

       openstack overcloud image upload --update-existing --whole-disk
      Copy to Clipboard Toggle word wrap
      注意

      即使 OpenStack 镜像服务中没有镜像,您也必须使用 --update-existing 标志。

  3. 在 overcloud 上启用 FIPS。

    为特定于您的环境的 overcloud 部署配置模板。在部署命令中包含所有配置模板,包括 fips.yaml :

    openstack overcloud deploy
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environents/fips.yaml
    Copy to Clipboard Toggle word wrap

第 10 章 提高用户访问安全性

重要

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

您可以在 Red Hat OpenStack Platform 17 中启用安全基于角色的访问控制(SRBAC)。根据项目范围内已存在的三个角色,SRBAC 模型有三个用户角色。

10.1. SRBAC personas

personas 是角色与它们所属的范围的组合。部署 Red Hat OpenStack Platform 17 时,您可以从项目范围内分配任何用户角色。

10.1.1. Red Hat OpenStack Platform SRBAC 角色

目前,项目范围内提供了三个不同的角色。

admin
admin 角色包括资源或 API 的所有创建、读取、更新或删除操作。
成员
member 角色可以创建、读取、更新和删除由其所属的范围拥有的资源。
读取器
reader 角色用于只读操作,无论它应用到的范围是什么。此角色可以查看应用资源的范围。

10.1.2. Red Hat OpenStack Platform SRBAC 范围

范围是执行操作的上下文。只有 项目范围 在 Red Hat OpenStack Platform 17 中提供。项目 范围是 OpenStack 中隔离自助服务资源的 API 子集。

10.1.3. Red Hat OpenStack Platform SRBAC personas

项目管理员

由于项目 admin 用户角色是唯一可用的管理人员,Red Hat OpenStack Platform 17 包含修改的策略,为项目管理员授予最高级别授权人员。此用户角色包括跨项目资源创建、读取、更新和删除操作,包括添加和删除用户和其他项目。

注意

该用户角色有望在未来的开发范围内更改范围。此角色表示赋予项目成员和项目读取器的所有权限。

项目成员
项目成员用户角色适用于被授予权限的用户,使其消耗项目范围内的资源。此用户角色可以在分配到的项目中创建、列出、更新和删除资源。此用户角色表示赋予项目读取器的所有权限。
项目读取器
项目读取器用于授予查看项目中非敏感资源的权限的用户。在项目中,将 reader 角色分配给需要检查或查看资源或审核员的最终用户,他们只需要查看单个项目中的特定于项目的资源,供审计的 Project-reader 用户角色不会解决所有审计用例。
注意

基于 systemdomain 范围的额外人员正在开发中,还不可用。

10.2. 激活安全基于角色的访问控制

当您激活基于角色的安全身份验证时,您要激活一组新的策略文件,该文件定义了分配给 Red Hat OpenStack Platform 环境中的用户的权限范围。

先决条件

  • 已安装 Red Hat OpenStack Platform director 环境。

流程

  • 在部署 Red Hat OpenStack Platform 时,将 enable-secure-rbac.yaml 环境文件包含在部署脚本中:

    openstack overcloud deploy --templates
    …
    -e /usr/share/openstack-tripleo-heat-templates/environments/enable-secure-rbac.yaml
    Copy to Clipboard Toggle word wrap

10.3. 在 SRBAC 环境中分配角色

使用 Red Hat OpenStack Platform 上的 SRBAC,您可以将用户分配给 project-adminproject-memberproject-reader 的角色。

先决条件

  • 您已部署了带有安全基于角色的访问控制(SRBAC)的 Red Hat OpenStack Platform。

流程

  • 使用以下语法使用 openstack role add 命令:

    • 分配 admin 角色:

      $ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> admin
      Copy to Clipboard Toggle word wrap
    • 分配 member 角色:

      $ openstack role add --user <user> --user-domain <domain> --project <project>  --project-domain <project-domain> member
      Copy to Clipboard Toggle word wrap
    • 分配 reader 角色:

      $ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> reader
      Copy to Clipboard Toggle word wrap
  • <user > 替换为一个现有用户以应用该角色。
  • < domain> 替换为角色应用到的域。
  • &lt;project> 替换为被授予该角色的项目。
  • <project-domain > 替换为项目所在的域。

第 11 章 策略(policy)

每个 OpenStack 服务都包含由访问策略管理的资源。例如,资源可能包括以下功能:

  • 创建和启动实例的权限
  • 将卷附加到实例的功能

如果您是 Red Hat OpenStack Platform (RHOSP)管理员,您可以创建自定义策略来引入具有不同访问权限级别的新角色,或更改现有角色的默认行为。

重要

红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。

11.1. 查看现有策略

通常位于 /etc/$service 目录中服务的策略文件。例如,Compute (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
    Copy to Clipboard Toggle word wrap

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

11.2. 了解服务策略

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

  • "context_is_admin": "role:admin"

    当 target 后出现 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 在目标后出现时,策略会在允许该操作前检查该用户是否为 admin。

11.3. 策略语法

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

"identity:create_user": "rule:admin_required"
Copy to Clipboard Toggle word wrap

字符左侧的部分描述了特权,以及右侧的部分来定义谁可以使用特权。 您还可以在右侧使用 Operator 来进一步控制范围:

  • ! - 无用户(包括 admin)都可以执行此操作。
  • @"" - Any 用户可以执行此操作。
  • not, and, or - 可以使用标准的操作符。

例如,以下设置表示没有用户创建新用户的权限:

"identity:create_user": "!"
Copy to Clipboard Toggle word wrap

11.4. 使用策略文件进行访问控制

重要

红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。

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

注意
  • 在生产环境中实施策略文件前,您必须完全测试对暂存环境中的策略文件的更改。
  • 您必须检查对访问控制策略的任何更改是否意外弱弱任何资源的安全性。另外,对 policy.json 文件的任何更改都会立即生效,不需要服务重启。

示例:创建高级用户角色

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

  • 启动一个实例。
  • 停止实例。
  • 管理连接到实例的卷。

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

  • Start an instance: "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"
  • 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

  1. 创建自定义 keystone 角色:

    $ openstack role create PowerUsers
    +-----------+----------------------------------+
    | Field     | Value                            |
    +-----------+----------------------------------+
    | domain_id | None                             |
    | id        | 7061a395af43455e9057ab631ad49449 |
    | name      | PowerUsers                      |
    +-----------+----------------------------------+
    Copy to Clipboard Toggle word wrap
  2. 将现有用户添加到角色中,并为项目分配角色:

    $ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
    Copy to Clipboard Toggle word wrap
    注意

    角色分配仅与一个项目配对。这意味着,当您为用户分配角色时,您也会同时定义 target 项目。如果您希望用户接收同一角色但针对不同的项目,则必须单独为它们分配角色,但以不同的项目为目标。

  3. 查看默认的 nova 策略设置:

    $ oslopolicy-policy-generator --namespace nova
    Copy to Clipboard Toggle word wrap
  4. 通过将以下条目添加到 /var/lib/config-data/puppet-generated/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"
    }
    Copy to Clipboard Toggle word wrap

    在保存文件并重启 nova 容器时,您将实施这些更改。添加到 PowerUsers keystone 角色的用户会收到这些特权。

11.5. 示例:根据属性限制访问

重要

红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。

您可以根据发出该 API 调用的用户属性,创建将限制对 API 调用的访问的策略。例如,以下默认规则指出,如果从管理上下文运行,或者令牌的用户 ID 与与目标关联的用户 ID 匹配,则允许密钥对删除。

"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"
Copy to Clipboard Toggle word wrap

注意:"新实施"功能无法保证在每个版本中都有相应的功能。因此,使用目标服务的现有策略惯例编写规则非常重要。有关查看这些策略的详情,请参阅查看现有策略。对于要部署它们的每个版本,所有策略都应该在非生产环境中测试,因为策略无法保证跨版本的兼容性。

根据上例,您可以制作 API 规则,根据是否拥有资源来限制用户访问权限。另外,属性可以与其他限制结合使用,以组成规则,如下例所示:

"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
Copy to Clipboard Toggle word wrap

考虑以上示例,您可以创建一个仅限于管理员和用户的唯一规则,然后使用该规则进一步限制操作:

"admin_or_user": "is_admin:True or user_id:%(user_id)s"
"os_compute_api:os-instance-actions": "rule:admin_or_user"
Copy to Clipboard Toggle word wrap

11.6. 使用 heat 修改策略

重要

红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。

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

Expand
表 11.1. 策略参数
参数描述

KeystonePolicies

为 OpenStack Identity (keystone)配置的策略哈希。

IronicApiPolicies

为 OpenStack Bare Metal (ironic) API 配置的策略哈希。

BarbicanPolicies

为 OpenStack Key Manager (barbican)配置的策略哈希。

NeutronApiPolicies

为 OpenStack Networking (neutron) API 配置的策略哈希。

SaharaApiPolicies

为 OpenStack 集群(sahara) API 配置的策略哈希。

NovaApiPolicies

为 OpenStack Compute (nova) API 配置的策略哈希。

CinderApiPolicies

为 OpenStack Block Storage (cinder) API 配置的策略哈希。

GlanceApiPolicies

为 OpenStack Image Storage (glance) API 配置的策略哈希。

HeatApiPolicies

为 OpenStack Orchestration (heat) API 配置的策略哈希。

要为服务配置策略,为策略参数指定一个哈希值,其中包含该服务的策略,例如:

  • OpenStack Identity (keystone)使用 KeystonePolicies 参数。在环境文件的 parameter_defaults 部分中设置此参数:

    parameter_defaults:
      KeystonePolicies: { keystone-context_is_admin: { key: context_is_admin, value: 'role:admin' } }
    Copy to Clipboard Toggle word wrap
  • OpenStack Compute (nova)使用 NovaApiPolicies 参数。在环境文件的 parameter_defaults 部分中设置此参数:

    parameter_defaults:
      NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '@' } }
    Copy to Clipboard Toggle word wrap

11.7. 审计您的用户和角色

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

先决条件

  • 已安装 Red Hat OpenStack Platform 环境。
  • 以 stack 身份登录 director。

流程

  1. 运行 openstack role list 命令以查看环境中当前的角色:

    openstack role list -c Name -f value
    
    swiftoperator
    ResellerAdmin
    admin
    _member_
    heat_stack_user
    Copy to Clipboard Toggle word wrap
  2. 运行 openstack role assignment list 命令,以列出属于特定角色的所有用户。例如,要查看具有 admin 角色的所有用户,请运行以下命令:

    $ openstack role assignment list --names --role admin
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | Role  | User                               | Group | Project         | Domain     | System | Inherited |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    | admin | heat-cfn@Default                   |       | service@Default |            |        | False     |
    | admin | placement@Default                  |       | service@Default |            |        | False     |
    | admin | neutron@Default                    |       | service@Default |            |        | False     |
    | admin | zaqar@Default                      |       | service@Default |            |        | False     |
    | admin | swift@Default                      |       | service@Default |            |        | False     |
    | admin | admin@Default                      |       | admin@Default   |            |        | False     |
    | admin | zaqar-websocket@Default            |       | service@Default |            |        | False     |
    | admin | heat@Default                       |       | service@Default |            |        | False     |
    | admin | ironic-inspector@Default           |       | service@Default |            |        | False     |
    | admin | nova@Default                       |       | service@Default |            |        | False     |
    | admin | ironic@Default                     |       | service@Default |            |        | False     |
    | admin | glance@Default                     |       | service@Default |            |        | False     |
    | admin | mistral@Default                    |       | service@Default |            |        | False     |
    | admin | heat_stack_domain_admin@heat_stack |       |                 | heat_stack |        | False     |
    | admin | admin@Default                      |       |                 |            | all    | False     |
    +-------+------------------------------------+-------+-----------------+------------+--------+-----------+
    Copy to Clipboard Toggle word wrap
    注意

    您可以使用 -f {csv,json,table,value,yaml} 参数导出这些结果。

11.8. 审计 API 访问

您可以审核给定角色可以访问的 API 调用。为每个角色重复此过程将导致全面报告每个角色可访问的 API。

先决条件

  • 作为目标角色中的用户提供的身份验证文件。
  • JSON 格式的访问令牌。
  • 您要审计的每个服务 API 的策略文件。

流程

  1. 首先,在所需角色中提供用户的身份验证文件。
  2. 捕获 Keystone 生成的令牌并将其保存到文件中。您可以通过运行任何 openstack-cli 命令并使用 --debug 选项进行此操作,该选项会将提供的令牌输出到 stdout。您可以复制此令牌并将其保存到访问文件中。使用以下命令作为单一步骤执行此操作:

    openstack token issue --debug 2>&1 | egrep ^'{\"token\":' > access.file.json
    Copy to Clipboard Toggle word wrap
  3. 创建策略文件。这可以在托管相关容器化服务的 overcloud 节点上完成。以下示例为 cinder 服务创建一个策略文件:

    ssh tripleo-admin@CONTROLLER-1 sudo podman exec cinder_api \
    oslopolicy-policy-generator \
    --config-file /etc/cinder/cinder.conf \
    --namespace cinder > cinderpolicy.json
    Copy to Clipboard Toggle word wrap
  4. 使用这些文件,您现在可以审核相关角色以访问 Cinder 的 API:

    oslopolicy-checker --policy cinderpolicy.json --access access.file.json
    Copy to Clipboard Toggle word wrap

第 12 章 网络时间协议

您需要确保 Red Hat OpenStack Platform 集群中的系统在系统间具有准确且一致的时间戳。

Red Hat Enterprise Linux 8 上的 Red Hat OpenStack Platform 支持 Chrony 进行时间管理。如需更多信息,请参阅使用 Chrony 套件配置 NTP

12.1. 为什么一致的时间非常重要

在整个机构中,对于操作和安全需求非常重要:

识别安全事件
持续计时可帮助您关联受影响系统上事件的时间戳,以便您可以了解事件序列。
身份验证和安全系统

安全系统对于时间偏移可能敏感,例如:

  • 基于 kerberos 的身份验证系统可能会拒绝验证受时钟偏移影响的客户端。
  • 传输层安全性(TLS)证书依赖于有效的时间源。如果客户端和服务器系统时间差超过 Valid From 日期范围,则客户端到服务器 TLS 连接会失败。
Red Hat OpenStack Platform 服务
某些 OpenStack 核心服务特别依赖于准确计时,包括高可用性(HA)和 Ceph。

12.2. NTP 设计

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

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

配置实例以接收来自您专用时间服务器的时间,而不是它们所在的主机。

注意

在 Red Hat OpenStack Platform 环境中运行的服务容器仍从它们所在的主机接收时间。

第 13 章 强化基础架构和虚拟化

您可以强化物理和虚拟环境,以更好地防止内部和外部威胁。

13.1. 用于 Red Hat OpenStack Platform 的 Harware

当您添加用于云环境中的硬件时,请确保支持硬件虚拟化。禁用不使用的硬件功能。

流程

  1. 检查 Red Hat OpenStack 认证的硬件,以确保您的硬件受支持。
  2. 检查硬件虚拟化是否可用并启用:

    cat /proc/cpuinfo | egrep "vmx|svm"
    Copy to Clipboard Toggle word wrap
  3. 确保所有固件在硬件平台上都处于最新状态。详情请查看硬件供应商文档。

13.2. 云环境中的软件更新

为安全、性能和支持保持 Red Hat OpenStack Platform (RHOSP)的更新。

  • 如果更新时会包括内核更新,您必须重启您更新的物理系统或实例。
  • 更新 OpenStack Image (glance)镜像,以确保新创建的实例具有最新的更新。
  • 如果您在 RHOSP 上有选择地更新软件包,请确保包括了所有安全更新。有关最新漏洞和安全更新的更多信息,请参阅:

13.3. 限制硬件和软件功能

仅启用您使用的硬件和软件功能,以便较少的代码暴露给攻击的可能性。一些功能应只在可信的环境中启用。

PCI 透传
PCI 透传允许实例直接访问节点上的 PCI 设备。具有 PCI 设备访问权限的实例可能允许恶意参与者对固件进行修改。另外,有些 PCI 设备具有直接内存访问(DMA)。当您为使用 DMA 的设备赋予实例控制时,它可以获得任意物理内存访问。

您必须为特定用例启用 PCI 透传,如网络功能虚拟化(NFV)。除非部署需要,否则不要启用 PCI 透传。

内核相同的页面合并
内核相同页面合并(KSM)是一种通过重复数据删除和共享内存页面减少内存使用的功能。当两个或更多虚拟机在内存中有相同的页面时,可以共享这些页面,从而提高密度。内存重复数据删除(Deduplication)策略容易受到侧信通道攻击的影响,且只应在可信环境中使用。在 Red Hat OpenStack Platform 中,默认禁用 KSM。

13.4. Red Hat OpenStack Platform 上的 SELinux

Security-Enhanced Linux (SELinux)是强制访问控制(MAC)的实现。MAC 通过限制允许进程或应用程序在系统上执行的操作来限制攻击的影响。有关 SELinux 的详情,请查看 什么是 SELinux?

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

Hypervisor 威胁
在实例内运行的被破坏的应用程序会攻击虚拟机监控程序访问底层资源。如果实例能够访问虚拟机监控程序操作系统,物理设备和其他应用程序可能会变为目标。这种威胁代表了重大风险。虚拟机监控程序上的折衷还可以破坏固件、其他实例和网络资源。
实例威胁
在实例内运行的被破坏的应用程序会攻击虚拟机监控程序访问或控制另一个实例及其资源,或者实例文件镜像。保护实际网络的管理策略不会直接应用到虚拟环境。因为每个实例都是 SELinux 标记的进程,所以每个实例有一个安全边界,由 Linux 内核强制使用。

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

13.5. 调查容器化服务

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

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

流程

  • 使用 'podman inspect 获取信息,如绑定挂载的主机目录:

    例如:

    $ sudo podman inspect <container_name> | less
    Copy to Clipboard Toggle word wrap

    将 <container_name> 替换为容器的名称。例如,nova 计算

  • 检查位于 /var/log/containers 中的服务的日志:

    例如:

    sudo less /var/log/containers/nova/nova-compute.log
    Copy to Clipboard Toggle word wrap
  • 在容器内运行交互式 CLI 会话:

    例如:

    podman exec -it nova_compute /bin/bash
    Copy to Clipboard Toggle word wrap
    注意

    您可以对服务进行更改,以直接在容器中测试目的。容器重启时,所有更改都会丢失。

13.6. 对容器化服务进行临时更改

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

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

流程

  1. 编辑绑定至 nova_compute 容器的 nova.conf 配置文件。将 debug 参数的值设置为 True

    $ sudo sed -i 's/^debug=.*/debug=True' \
    /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf
    Copy to Clipboard Toggle word wrap
    警告

    OpenStack 文件的配置文件是 ini 文件,其中包括多个部分,如 [DEFAULT][database]。在整个文件中,每个部分独有的参数可能并不唯一。请谨慎使用 sed。您可以通过运行 egrep -v "^$|^#" [configuration_file] | grep [parameter] 以检查一个参数是否在配置文件中出现了多次。

  2. 重启 nova 容器:

    sudo podman restart nova_compute
    Copy to Clipboard Toggle word wrap

13.7. 对容器化服务进行永久更改

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

流程

  1. 创建一个名为 libvirt-keysize.yaml 的新 yaml 模板,并使用 LibvirtCertificateKeySize 参数将默认值从 2048 增加到 4096

    cat > /home/stack/templates/libvirt-keysize.yaml
    parameter_defaults:
            LibvirtCertificateKeySize: 4096
    EOF
    Copy to Clipboard Toggle word wrap
  2. libvirt-keysize.yaml 配置文件添加到部署脚本中:

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/libvirt-keysize.yaml
    ...
    Copy to Clipboard Toggle word wrap
  3. 重新运行部署脚本:

    ./deploy.sh
    Copy to Clipboard Toggle word wrap

13.8. 固件更新

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

13.9. 使用 SSH 横幅文本

您可以设置横幅,向通过 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.*
   ******************************************************************
Copy to Clipboard Toggle word wrap

要将此更改应用到您的部署,请将设置保存为名为 ssh_banner.yaml 的文件,然后将其传递到 overcloud deploy 命令,如下所示:& lt;full environment > 表示您必须仍然包含所有原始部署参数。例如:

    openstack overcloud deploy --templates \
      -e <full environment> -e  ssh_banner.yaml
Copy to Clipboard Toggle word wrap

13.10. 系统事件的审计

维护所有审计事件的记录可帮助您建立系统基准、执行故障排除或分析导致特定结果的事件序列。审计系统可以记录许多类型的事件,如更改系统时间、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
Copy to Clipboard Toggle word wrap

13.11. 管理防火墙规则

防火墙规则在部署过程中自动应用到 overcloud 节点上,旨在仅公开获取 OpenStack 工作所需的端口。您可以根据需要指定额外的防火墙规则。例如,要为 Zabbix 监控系统添加规则:

parameter_defaults:
  ControllerExtraConfig:
    ExtraFirewallRules:
      '301 allow zabbix':
      dport: 10050
      proto: tcp
      source: 10.0.0.8
Copy to Clipboard Toggle word wrap
注意

如果没有设置 action 参数,则结果将 接受。您只能将 action 参数设置为 drop,insert, 或 append

您还可以添加限制访问的规则。在规则定义中使用的数字将决定规则的优先级。例如,Rabx 的规则号默认为 109。如果要静止它,您可以将其切换为使用较低值:

parameter_defaults:
  ControllerParameters
    ExtraFirewallRules:
      '098 allow rabbit from internalapi network':
        dport: [4369,5672,25672]
        proto: tcp
        source: 10.0.0.0/24
      '099 drop other rabbit access:
        dport: [4369,5672,25672]
        proto: tcp
        action: drop
Copy to Clipboard Toggle word wrap

在本例中,098099 是任意选择的数字,它们小于 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
Copy to Clipboard Toggle word wrap

或者,您还可以从 puppet 定义中提取端口要求。例如,RabbitMQ 的规则存储在 puppet/services/rabbitmq.yaml 中:

    ExtraFirewallRules:
      '109 rabbitmq':
        dport:
          - 4369
          - 5672
          - 25672
Copy to Clipboard Toggle word wrap

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

  • dport :与规则关联的目的地端口。
  • S PORT :与规则关联的源端口。
  • Proto :与规则关联的协议。默认为 tcp
  • action :与规则关联的操作策略。默认为 INSERT,并将 jump 设置为 ACCEPTS
  • State: 与规则关联的状态阵列。默认为 [新增]
  • source: 与规则关联的源 IP 地址。
  • Interface: 与规则关联的网络接口。
  • :与规则关联的链。默认为 INPUT
  • Destination: 与规则关联的目的地 cidr。

13.12. 使用 AIDE 进行入侵检测

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
Copy to Clipboard Toggle word wrap
注意

上面的示例没有主动维护或基准测试,因此您应该选择符合您的要求的 AIDE 值。

  1. 声明了一个名为 TripleORules 的别名,以避免每次都重复使用相同的属性。
  2. 别名接收 p+sha256 属性。在 AIDE 术语中,这会被解释为:监视所有文件权限 p,带有完整性 checksum sha256

有关 AIDE 配置文件可用属性的完整列表,请参见 的 AIDE MAN 页面(https://aide.github.io/)。

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

  1. 将设置保存为 /home/stack/templates/ 目录中的名为 aide.yaml 的文件。
  2. 编辑 aide.yaml 环境文件,使其具有适合您环境的参数和值。
  3. openstack overcloud deploy 命令中包含 /home/stack/templates/aide.yaml 环境文件,以及特定于您环境的所有其他必要的 heat 模板和环境文件:

    openstack overcloud deploy --templates
    ...
    -e /home/stack/templates/aide.yaml
    Copy to Clipboard Toggle word wrap

13.12.1. 使用复杂 AIDE 规则

可使用前面描述的格式创建复杂的规则。例如:

    MyAlias = p+i+n+u+g+s+b+m+c+sha512
Copy to Clipboard Toggle word wrap

以上命令将转换为以下指令:监控权限、索引节点、链接数、用户、组、大小、块数、mtime、ctime,使用 sha256 (校验和生成)。

请注意,别名始终应具有 1 的顺序位置,这意味着它位于 AIDE 规则的顶部,并递归应用到下面所有值。

在别名后,以下是要监控的目录。请注意,可以使用正则表达式。例如,我们为 var 目录设置了监控,但使用了 not(!)语句('!/var/log.*''!/var/spool.*')进行了覆盖。

13.12.2. 其他 AIDE 值

还提供以下 AIDE 值:

AideConfPath :到 aide 配置文件的完整路径,默认为 /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 中设置的电子邮件地址。

13.12.3. AIDE 的 cron 配置

AIDE director 服务允许您配置 cron 任务。默认情况下,它将报告发送到 /var/log/audit/ ;如果您想要使用电子邮件警报,则启用 AideEmail 参数,以将警报发送到配置的电子邮件地址。请注意,依赖关键警报的电子邮件可能会受到系统中断和不必要消息过滤的影响。

13.12.4. 考虑系统升级的影响

执行升级时,AIDE 服务将自动重新生成一个新的完整性数据库,以确保正确计算所有升级的文件,使其具有更新的校验和。

如果 openstack overcloud deploy 被调用为初始部署的后续运行,并且更改了 AIDE 配置规则,则 director AIDE 服务将重建数据库,以确保新配置属性封装在完整性数据库中。

13.13. 查看 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
      - tty6
Copy to Clipboard Toggle word wrap

13.14. Identity Service 的 CADF 审计

全面的审计流程可帮助您审查 OpenStack 部署的持续安全状况。这对 keystone 尤为重要,因为它在安全模型中扮演了角色。

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

  parameter_defaults:
    KeystoneNotificationFormat: cadf
Copy to Clipboard Toggle word wrap

13.15. 查看 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
Copy to Clipboard Toggle word wrap

第 14 章 强化仪表板服务

Dashboard 服务(horizon)为用户提供一个自助服务门户,以便在管理员设置的限制范围内置备自己的资源。使用与 OpenStack API 相同的敏感度管理 Dashboard 服务的安全性。

14.1. 调试仪表板服务

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

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

14.2. 选择域名

最佳实践是将 Dashboard 服务(horizon)部署到第二个级别域,而不是在任何级别上共享域。如下提供了每个方面的示例:

  • 第二级域: https://example.com
  • 共享子域 :https://example.public-url.com

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

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

注意

不支持在裸机域(如 https://example/ )上部署 Dashboard 服务。

14.3. 配置 ALLOWED_HOSTS

Horizon 基于 python Django Web 框架构建,需要对与误导 HTTP 主机标头相关的安全威胁进行保护。若要应用此保护,请将 ALLOWED_HOSTS 设置配置为使用 OpenStack 控制面板提供的 FQDN。

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

流程

  1. 在模板中的 parameter_defaults 下,设置 HorizonAllowedHosts 参数的值:

    parameter_defaults:
        HorizonAllowedHosts: <value>
    Copy to Clipboard Toggle word wrap

    <value> 替换为 OpenStack 仪表板提供的 FQDN。

  2. 使用修改后的模板以及您的环境所需的所有其他模板,部署 overcloud。

14.4. 跨站点脚本(XSS)

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

  • mark_safe 函数。
  • is_safe - 用于自定义模板标签。
  • safe 模板标签。
  • 任何位置自动转义会被关闭,任何可能会评估错误转义的数据的 JavaScript。

14.5. 跨站点请求 Forgery (CSRF)

使用多个 JavaScript 实例的仪表板应该被审核为漏洞,如不正确的使用 @csrf_exempt decorator。在降低 CORS (Cros Origin Resource Sharing)限制前,评估未遵循推荐的安全设置的任何仪表板。将您的 Web 服务器配置为发送带有每个响应的限制的 CORS 标头。只允许仪表板域和协议,例如:Access-Control-Allow-Origin: https://example.com/。您不应该允许通配符来源。

14.6. 允许 iframe 嵌入

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

流程

  • 您可以使用以下参数来允许 iframe 嵌入:
    parameter_defaults:
      ControllerExtraConfig:
        horizon::disallow_iframe_embed: false
Copy to Clipboard Toggle word wrap
注意

只有在完全理解潜在的安全影响后,这些设置才应设置为 False

14.7. 为仪表板流量使用 HTTPS 加密

建议您使用 HTTPS 加密仪表板流量。您可以将其配置为使用来自可识别的证书认证机构(CA)的有效可信证书。只有在所有用户浏览器中预先安装信任的根证书时,才会适当地发布私有证书。

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

如需更多信息,请参阅 第 7 章 在 overcloud 公共端点中启用 SSL/TLS

14.8. HTTP 严格传输安全性(HSTS)

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

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

horizon::enable_secure_proxy_ssl_header: true
Copy to Clipboard Toggle word wrap

验证

部署 overcloud 后,检查 Red Hat OpenStack Dashboard (horizon)的 local_settings 文件进行验证。

  1. 使用 ssh 连接到控制器:

    $ ssh tripleo-admin@controller-0
    Copy to Clipboard Toggle word wrap
  2. 检查 SECURE_PROXY_SSL_HEADER 参数的值为 ('HTTP_X_FORWARDED_PROTO', 'https')

    sudo egrep ^SECURE_PROXY_SSL_HEADER /var/lib/config-data/puppet-generated/horizon/etc/openstack-dashboard/local_settings
    SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
    Copy to Clipboard Toggle word wrap

14.9. 前端缓存

不建议将前端缓存工具与控制面板搭配使用,因为它会呈现直接从 OpenStack API 请求生成的动态内容。因此,前端缓存层(如 varnish )可能会阻止显示正确的内容。控制面板使用 Django,它直接从 Web 服务提供静态介质,并且已经受益于 Web 主机缓存。

14.10. 会话后端

对于基于 director 的部署,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'
Copy to Clipboard Toggle word wrap

14.11. 查看 secret 密钥

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

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

14.12. 配置会话 Cookie

控制面板会话 Cookie 可以打开,以通过浏览器技术(如 JavaScript)进行交互。对于随处带有 TLS 的 director 部署,您可以使用 HorizonSecureCookies 设置来强化此行为。

注意

切勿将 CSRF 或会话 Cookie 配置为使用带有前导点的通配符域。

14.13. 静态介质

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

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

14.14. 验证密码复杂性

OpenStack Dashboard (horizon)可以使用密码验证检查来强制实施密码复杂性。

流程

  1. 指定用于密码验证的正则表达式,以及用于失败测试的帮助文本。以下示例要求用户创建长度为 8 到 18 个字符之间的密码:
    parameter_defaults:
      HorizonPasswordValidator: '^.{8,18}$'
      HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'
Copy to Clipboard Toggle word wrap
  1. 将此更改应用到您的部署。将设置保存为名为 horizon_password.yaml 的文件,然后将其传递给 overcloud 部署命令,如下所示:& lt;full environment > 表示您必须仍然包含所有原始部署参数。例如:
    openstack overcloud deploy --templates \
      -e <full environment> -e  horizon_password.yaml
Copy to Clipboard Toggle word wrap

14.15. 强制管理员密码检查

以下设置默认设置为 True,但如果需要,可以使用环境文件来禁用它。

注意

只有在完全理解潜在的安全影响后,这些设置才应设置为 False

流程

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

  • 您可以使用环境文件禁用 ENFORCE_PASSWORD_CHECK
    parameter_defaults:
      ControllerExtraConfig:
        horizon::enforce_password_check: false
Copy to Clipboard Toggle word wrap

14.16. 禁用显示的密码

disable_password_reveal 参数默认设置为 True,但如果需要,可以使用环境文件来禁用它。密码图示按钮允许用户在仪表板中查看他们要输入的密码。

流程

  • ControllerExtraConfig 参数下,包含 horizon::disable_password_reveal: false。将它保存到 heat 环境文件中,并将它包含在您的部署命令中。

Example

parameter_defaults:
  ControllerExtraConfig:
    horizon::disable_password_reveal: false
Copy to Clipboard Toggle word wrap

注意

只有在完全理解潜在的安全影响后,这些设置才应设置为 False

14.17. 为仪表板显示登录标语

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

在自定义仪表板容器中,您可以通过手动编辑 /usr/share/openstack-dashboard/openstack_dashboard/themes/rcue/templates/auth/login.html 文件来创建 logon 横幅:

流程

  1. 只在 {% 包括 '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>
    Copy to Clipboard Toggle word wrap

上例生成类似如下的仪表板:

logonbanner

其他资源

14.18. 限制文件上传的大小

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

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

重要

此设置尚未由红帽正式测试。建议您在将此设置部署到生产环境中前全面测试此设置的影响。

注意

如果值太小,文件上传将失败。

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

  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf/httpd.conf

    <Directory />
      LimitRequestBody 10737418240
    </Directory>
    Copy to Clipboard Toggle word wrap
  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/10-horizon_vhost.conf

    <Directory "/var/www">
      LimitRequestBody 10737418240
    </Directory>
    Copy to Clipboard Toggle word wrap
  • /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/15-horizon_ssl_vhost.conf

    <Directory "/var/www">
      LimitRequestBody 10737418240
    </Directory>
    Copy to Clipboard Toggle word wrap
注意

这些配置文件由 Puppet 管理,因此每当您运行 openstack overcloud deploy 过程时,任何非受管更改都会被覆盖。

第 15 章 强化网络服务

Networking 服务 (neutron) 是 Red Hat OpenStack Platform (RHOSP) 的软件定义型网络 (SDN) 组件。RHOSP 网络服务管理进出虚拟机实例的内部和外部流量,并提供路由、分段、DHCP 和元数据等核心服务。它为虚拟网络功能提供 API,并管理交换机、路由器、端口和防火墙。

有关 Red Hat OpenStack Platfrom 网络服务的更多信息,请参阅 网络指南

本节讨论 OpenStack 网络配置的良好做法,因为它们适用于 OpenStack 部署中的项目网络安全性。

15.1. 限制 API 服务器的绑定地址:neutron-server

要限制 OpenStack Networking API 服务绑定传入客户端连接的网络套接字的接口或 IP 地址,请在 /var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 文件中指定 bind_hostbind_port

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

# Port the bind the API server to
bind_port = 9696
Copy to Clipboard Toggle word wrap

15.2. 项目网络服务工作流

OpenStack 网络为用户提供网络资源的自助服务配置。在为用户提供创建、更新和销毁可用网络资源的能力时,云架构师和操作员会评估其设计用例。

15.3. 网络资源策略引擎

OpenStack 网络内的策略引擎及其配置文件(policy.json)提供了一种方法来提供对项目网络方法和对象的用户更精细的授权。OpenStack 网络策略定义会影响网络可用性、网络安全性和整个 OpenStack 安全性。云架构师和操作员应仔细评估他们对管理网络资源的用户和项目访问权限的策略。

注意

查看默认网络资源策略非常重要,因为此策略可以进行修改以适合您的安全状况。

如果您的 OpenStack 部署提供了多个外部访问点到不同的安全区,您可以限制项目将多个 vNIC 附加到多个外部访问点的角度,这会使这些安全区桥接这些安全区,并可能导致无法预见的安全隐患。您可以使用计算提供的主机聚合功能,或者将项目实例分成具有不同虚拟网络配置的多个项目中,以帮助缓解这一风险。如需有关主机聚合的更多信息,请参阅 创建和管理主机聚合

15.4. 安全组

安全组是安全组规则的集合。借助安全组及其规则,管理员可以指定允许通过虚拟接口端口的流量和方向(ingress/egress)类型。在 OpenStack 网络中创建虚拟接口端口时,它会与安全组关联。规则可以添加到 default 安全组,以便基于每个部署来更改行为。

在使用计算 API 修改安全组时,更新的安全组将应用到实例上的所有虚拟接口端口。这是因为 Compute 安全组 API 基于实例,而不是基于端口,如 neutron 中找到。

15.5. 缓解 ARP 欺骗

OpenStack 网络具有内置功能,可帮助缓解对实例的 ARP 欺骗。除非将仔细考虑给生成的风险,否则不应该禁用。

15.6. 使用安全协议进行身份验证

/var/lib/config-data/puppet-generated/neutron/etc/neutron/neutron.conf 中检查 [keystone_authtoken] 部分下的 auth_uri 的值是否已设置为以 'https 开头的 Identity API 端点:

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

计算实例使用行业标准存储协议(如 iSCSI、ATA 通过以太网或光纤通道)检索块存储。这些资源通过 OpenStack 原生标准 HTTP RESTful API 管理和配置。

16.1. 为请求主体设置最大大小

如果没有定义每个请求的最大正文大小,攻击者可以设计大型大小的任意 OSAPI 请求,从而导致服务崩溃,最后导致拒绝服务攻击。分配 t he maximum value 可确保任何恶意的请求都会被阻止确保服务持续可用。

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

16.2. 启用卷加密

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

16.3. 卷 Wiping

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

注意

在以前的版本中,lvm_type=default 用于表示擦除。虽然此方法仍然可以正常工作,但不建议在设置 secure delete 时 lvm_type=default

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

第 17 章 强化共享文件系统(Manila)

共享文件系统服务(manila)提供一组在多项目云环境中管理共享文件系统的服务。通过 manila,您可以创建共享文件系统并管理其属性,如可见性、可访问性和配额。

有关 manila 的更多信息,请参阅存储指南: https://access.redhat.com/documentation/zh-cn/red_hat_openstack_platform/17.0/html-single/storage_guide/

17.1. manila 的安全注意事项

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        |
 +-------------+-----------------------------------------+
Copy to Clipboard Toggle word wrap

默认情况下,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
Copy to Clipboard Toggle word wrap

建议您将 manila 配置为在非 root 服务帐户下运行,并更改文件权限,以便只有系统管理员可以修改它们。Manila 应该只有管理员能够写入配置文件,服务只能通过 manila 组中的组成员资格读取它们。其他用户无法读取这些文件,因为它们包含服务帐户密码。

注意

只有 root 用户应该可以写入 rootwrap.conf 中的 manila-rootwrap 配置,manila-rootwrap 命令会过滤 rootwrap.d/share.filters 中的共享节点。

17.2. manila 的网络和安全模型

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

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

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

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

17.3. 共享后端模式

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

  • 共享服务器 - driver_handles_share_servers = True - 共享驱动程序创建共享服务器并管理共享服务器生命周期。
  • 无共享服务器 - driver_handles_share_servers = False - 管理员(而不是共享驱动程序)使用网络接口管理裸机存储,而不依赖于共享服务器。

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

注意

在没有共享服务器模式 中,manila 将假定通过导出任何共享的网络接口都可以被所有项目访问。

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

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

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

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

17.4. manila 的网络要求

Manila 可以与不同的网络类型集成: 扁平GREVLANVXLAN

注意

Manila 仅将网络信息存储在数据库中,包含由网络供应商提供的实际网络。Manila 支持使用 OpenStack Networking 服务(neutron)和"standalone"预先配置的网络。

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

  • 共享服务器 后端模式中的扁平网络
  • 共享服务器 后端模式中的分段网络

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

注意

由某些共享驱动程序生成的共享服务器是利用计算服务创建的计算服务器。其中一些驱动程序不支持网络插件。

创建共享网络后,manila 会检索由网络提供者决定的网络信息:网络类型、分段标识符(如果网络使用分段)和从中分配网络的 IP 块。

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

注意

有些共享驱动程序可能不支持所有类型的分段,更多详情请参阅您要使用的驱动程序的规格。

17.5. 使用 manila 的安全服务

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

17.6. 安全服务简介

创建共享并获得其导出位置后,用户没有权限挂载并在处理文件。用户需要明确授予新共享的访问权限。

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

注意

在某些情况下,需要明确指定其中一个安全服务,例如 NetApp、EMC 和 Windows 驱动程序需要 Active Directory 来使用 CIFS 协议创建共享。

17.7. 安全服务管理

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

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

  • 项目提供安全服务的详细信息。
  • 管理员负责安全服务:它们配置此类安全服务的服务器端。
  • 在 manila API 中,security_serviceshare_networks 关联。
  • 共享驱动程序使用安全服务中的数据来配置新创建的共享服务器。

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

  • LDAP - 轻量级目录访问协议。用于通过 IP 网络访问和维护分布式目录信息服务的应用程序协议。
  • Kerberos - 通过网络验证协议,该协议基于票据,以允许节点通过非安全网络进行通信,以安全的方式证明其身份。
  • Active Directory - Microsoft 为 Windows 域网络开发的目录服务。使用 LDAP、Microsoft 的版本 Kerberos 和 DNS。

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

  • 项目网络中使用的 DNS IP 地址。
  • 安全服务的 IP 地址或主机名。
  • 安全服务的域。
  • 项目使用的用户或组名称。
  • 如果您指定了用户名,则用户的密码。

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

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

注意

不同的共享驱动程序支持不同的身份验证服务。有关支持不同驱动程序的功能的详情,请参考 https://docs.openstack.org/manila/latest/admin/share_back_ends_feature_support_mapping.html

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

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

注意

在大多数情况下,支持 CIFS 共享文件系统协议的驱动程序可以配置为使用 Active Directory 并通过用户身份验证管理访问权限。

  • 支持 GlusterFS 协议的驱动程序可以使用 TLS 证书进行身份验证。
  • 使用支持使用 IP 地址进行 NFS 协议身份验证的驱动程序是唯一支持的选项。
  • 由于 HDFS 共享文件系统协议使用 NFS 访问,因此也可以将其配置为使用 IP 地址进行身份验证。

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

17.8. 共享访问控制

用户可以指定哪些特定客户端有权访问其创建的共享。由于 keystone 服务,单个用户创建的共享仅对同一项目中自己和其他用户可见。Manila 允许用户创建"公共"可见的共享。这些共享在属于其他 OpenStack 项目的用户仪表板中可见,如果所有者授予了访问权限,他们甚至可以挂载这些共享,即使在网络上可以访问这些共享。

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

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

注意

Manila 不提供存储系统的端到端管理。您仍需要单独保护后端系统不受未授权访问的影响。因此,如果某人破坏了后端存储设备,则 manila API 提供的保护仍然可以被忽略,从而无法取消访问。

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

使用 manila,您可以通过指定这些支持的共享访问级别之一来授予或拒绝对共享的访问:

  • rw - Read 和 write (RW)访问。这是默认值。
  • ro- Read-only (RO)访问。
注意

当管理员向某些特定编辑器或贡献者提供读写(RW)访问权限时,RO 访问级别对公共共享很有用,并为其余用户(viewers)提供只读(RO)访问权限。

您还必须指定这些支持的身份验证方法之一:

  • ip - 使用 IP 地址来验证实例。可以通过以 CIDR 表示法以正确的 IPv4 或 IPv6 地址为客户端提供 IP 访问。
  • 证书 - 使用 TLS 证书来验证实例。将 TLS 身份指定为 IDENTKEY。有效值是证书通用名称(CN)中最多 64 个字符的字符串。
  • user - 由指定用户或组名称进行授权。有效值是一个字母数字字符串,可包含一些特殊字符,长度从 4 到 32 个字符。
注意

支持的身份验证方法取决于您使用的共享驱动程序、安全服务和共享文件系统协议。支持的共享文件系统协议包括 MapRFS、CEPHFS、NFS、CIFS、GlusterFS 和 HDFS。支持的安全服务包括 LDAP、Kerberos 协议或 Microsoft Active Directory 服务。

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

注意

当您为您的共享选择安全服务时,您需要考虑共享驱动程序是否可以使用可用的身份验证方法创建访问规则。支持的安全服务包括 LDAP、Kerberos 和 Microsoft Active Directory。

17.9. 共享类型访问控制

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

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

默认情况下,共享类型创建为公共类型。在创建共享类型时,use- 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 |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
Copy to Clipboard Toggle word wrap

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|
 +----+--------+-----------+-----------+----------------------------------+----------------------+
Copy to Clipboard Toggle word wrap

管理员可以授予 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
Copy to Clipboard Toggle word wrap

因此,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 |
 +----+--------+-----------+-----------+-----------------------------------+-----------------------+
Copy to Clipboard Toggle word wrap

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

注意

对于演示共享类型的用途的示例,请考虑有两个后端:LVM 作为公共存储,Ceph 作为私有存储。在这种情况下,您可以使用 用户/组 身份验证方法授予对某些项目的访问权限并控制访问权限。

17.10. 策略(policy)

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

注意

配置文件 policy.json 可以在任何位置放置。默认预期,路径 /var/lib/config-data/puppet-generated/manila/etc/manila/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": "",
   }
Copy to Clipboard Toggle word wrap

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

注意

/var/lib/config-data/puppet-generated/manila/etc/manila/policy.json 的任何更改都会立即生效,允许在 manila 运行时实施新的策略。对策略进行手动修改可能会造成意外的副作用,因此不鼓励。Manila 不提供默认策略文件;所有默认策略都位于代码库中。您可以通过执行 oslopolicy-sample-generator --config-file=var/lib/config-data/puppet-generated/manila/etc/manila/manila-policy-generator.conf来生成默认策略

第 18 章 对象存储

Object Storage (swift)服务通过 HTTP 存储并检索数据。对象(数据的格式)存储在组织层次结构中,可以配置为提供匿名只读访问权限、ACL 定义访问权限甚至临时访问。Swift 支持多种通过中间件实施的基于令牌的身份验证机制。

应用使用行业标准 HTTP RESTful API 在对象存储中存储和检索数据。后端 swift 组件遵循相同的 RESTful 模型,虽然一些 API (如这些管理持久性)保持对集群私有的。

swift 的组件属于以下主要组:

  • 代理服务
  • 身份验证服务
  • 存储服务

    • 帐户服务
    • 容器服务
    • 对象服务
注意

对象存储安装不必面向互联网,也可能是带有机构内部网络基础架构的一部分的公共交换机的私有云。

18.1. 网络安全性

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

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

注意

Swift 不使用加密或身份验证与节点间通信。这是因为 swift 在性能方面使用了原生 rsync 协议,而不对 rsync 通信使用 SSH。这就是您在架构图中看到私有交换机或专用网络([V]LAN)的原因。此数据区域也应当与其他 OpenStack 数据网络分开。

注意

将私有(V) LAN 网络段用于您的数据区中的存储节点。

这要求代理节点具有双接口(物理或虚拟):

  • 一个接口作为消费者访问的公共接口。
  • 另一个接口作为可访问存储节点的私有接口。

下图展示了一个可能的网络架构,使用带有管理节点(OSAM)的对象存储网络架构:

18.2. 以非 root 用户身份运行服务

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

18.3. 文件权限

/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 {} \;
Copy to Clipboard Toggle word wrap

此限制仅允许 root 修改配置文件,同时仍然允许服务读取这些文件,因为其在 swift 组中的成员资格。

18.4. 保护存储服务

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

  • 帐户服务 - TCP/6002
  • 容器服务 - TCP/6001
  • 对象服务 - TCP/6000
  • Rsync - TCP/873
注意

如果使用 ssync 而不是 rsync,则使用对象服务端口来维护其持久性。

注意

在存储节点中不会发生身份验证。如果您能够在其中一个端口上连接到存储节点,您可以在不身份验证的情况下访问或修改数据。为了帮助缓解这个问题,您应该遵循之前使用私有存储网络的建议。

18.5. Object Storage 帐户术语

swift 帐户不是用户帐户或凭据。存在以下区别:

  • Swift 帐户 - 容器的集合(而不是用户帐户或身份验证)。您使用的身份验证系统将决定哪些用户与帐户相关联,以及它们如何访问它。
  • Swift 容器 - 对象的集合。容器的元数据可用于 ACL。ACL 的使用取决于所使用的身份验证系统。
  • Swift 对象 - 实际数据对象。对象级别的 ACL 也可用于元数据,并依赖于所使用的身份验证系统。

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

18.6. 保护代理服务

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

18.7. 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 或负载均衡器的 URL)获得响应。

18.8. 负载均衡器

如果使用 Apache 的选项不可行,或者您想要卸载 TLS 工作的性能,您可能会使用专用的网络设备负载均衡器。这是使用多个代理节点时提供冗余和负载平衡的一种常见方法。

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

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

18.9. 对象存储身份验证

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

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

18.10. 加密 at-rest swift 对象

Swift 可以与 Barbican 集成,以透明地加密和解密您存储的(at-rest)对象。at-rest 加密与转换加密不同,它指的是在磁盘上存储时加密的对象。

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

18.11. 其他项目

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

这个值最初应该使用加密安全随机数生成器设置,并在所有节点上保持一致。确保通过正确的 ACL 对其进行保护,并且您有备份副本以避免数据丢失。

第 19 章 监控和日志记录

日志管理是监控 OpenStack 部署安全状态的重要组件。日志除了组成您的 OpenStack 部署的组件活动外,还深入了解管理员、项目和实例的 BAU 操作。

日志不仅对主动安全性和持续合规活动而言是价值,而且它们是用于调查和事件响应的宝贵信息来源。例如,分析 keystone 访问日志可能会提醒您失败的登录、频率、原始 IP 以及事件是否仅限于选择帐户,以及其他相关信息。

director 包括使用 AIDE 的入侵检测功能,以及 keystone 的 CADF 审计功能。如需更多信息,请参阅 强化基础架构和虚拟化

19.1. 强化监控基础架构

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

19.2. 要监控的事件示例

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

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

重要

此列表并非详尽。您需要考虑可能适用于特定网络的其他用例,并且您可能认为可能存在异常行为。

  • 检测没有日志生成是高值的事件。这种差距可能会表示服务失败,甚至是临时关闭日志记录或修改日志级别来隐藏其跟踪的服务故障。
  • 未调度的应用程序事件(如启动或停止事件)可能会有潜在的安全隐患。
  • OpenStack 节点上的操作系统事件,如用户登录或重启。他们可以提供宝贵洞察力,以区分正确和不当的系统使用。
  • 网络桥接关闭。由于服务中断的风险,这是一个可操作的事件。
  • iptables 在 Compute 节点上清空事件,从而丢失对实例的访问。

为了降低用户、项目或域删除中出现孤立实例的安全风险,讨论了在系统上生成通知,并让 OpenStack 组件根据适当的情况响应这些事件,如终止实例、断开附加卷、回收 CPU 和存储资源等。

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

第 20 章 项目的数据隐私

OpenStack 旨在支持具有不同数据要求的项目之间的多租户。云操作员需要考虑其适用的数据隐私问题和法规。本章解决了用于 OpenStack 部署的数据驻留的方面和建议。

20.1. 数据驻留

在过去的数年里,数据隐私和隔离一直被认为是云采用的主要障碍。关注谁在云中拥有数据,以及云操作员是否被信任为这一数据的 custodian,过去有很大的问题。

某些 OpenStack 服务有权访问属于项目或引用项目信息的数据和元数据。例如,存储在 OpenStack 云中的项目数据可能包括以下项目:

  • 对象存储对象。
  • 计算实例临时文件系统存储.
  • 计算实例内存.
  • 块存储卷数据。
  • 用于计算访问的公钥。
  • 镜像服务中的虚拟机镜像。
  • 实例快照.
  • 传递给 Compute 的配置驱动器扩展的数据。

OpenStack 云存储的元数据包括以下项目(此列表不明确):

  • 机构名称。
  • 用户的"真实名称"。
  • 正在运行的实例、存储桶、对象、卷和其他与配额相关的项目的数量或大小。
  • 运行或存储数据的小时数。
  • 用户的 IP 地址。
  • 内部为计算镜像捆绑生成私钥。

20.2. 数据处理

良好的实践建议,在组织控制外或发布机构控制前,操作员必须清理云系统介质(数字和非数字)。根据信息的特定安全域和敏感度,Sanitization 方法应实施适当的强度和完整性级别。

注意

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.
Copy to Clipboard Toggle word wrap

在开发常规数据处理和清理指南时,云操作员应考虑以下事项(根据 NIST 推荐的安全控制):

  • 跟踪、记录和验证介质清理和处理操作。
  • 测试清理设备和流程以验证适当的性能。
  • 在将此类设备连接到云基础架构之前,清理可移植的可移动存储设备。
  • 销毁无法清理的云系统介质。

因此,OpenStack 部署需要解决以下做法(例如,其他部署):

  • 保护数据纠删代码
  • 实例内存清理
  • 块存储卷数据
  • 计算实例临时存储
  • 裸机服务器清理

20.2.1. 不安全地清除数据

在 OpenStack 中,可能会删除一些数据,但无法象上述 NIST 标准上下文中那样安全地清除。这通常适用于存储在数据库中的最大或全部定义元数据和信息。这可能会使用用于自动 vacuuming 和定期可用空间的数据库和/或系统配置来修复。

20.2.2. 实例内存清理

特定于各种虚拟机监控程序是实例内存的处理。此行为在计算中不定义,但通常预期虚拟机监控程序在删除实例时能够尽力清理内存,在实例创建时或两者都具有最佳工作。

20.3. 加密 Cinder 卷数据

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

如果没有使用 OpenStack 卷加密功能,则其他方法通常更难以启用。如果使用后端插件,则可能独立执行加密或非标准覆盖解决方案。OpenStack 块存储的插件以各种方式存储数据。许多插件都特定于供应商或技术,而其他插件更围绕文件系统(如 LVM 或 ZFS)相关解决方案。安全销毁数据的方法因插件、供应商和文件系统而异。

有些后端(如 ZFS)支持写时复制,以防止数据暴露。在这些情况下,从未编写的块读取始终返回零。其他后端(如 LVM)可能无法原生支持,因此 cinder 插件负责覆盖之前写入的块,然后再将它们发送给用户。务必要检查您选择的卷后端提供哪些保证,并查看哪些补救可用于这些保证。

20.4. 镜像服务延迟删除功能

镜像服务有一个延迟删除功能,该功能将在指定时间段内删除镜像。如果这种行为是安全问题,请考虑禁用此功能;您可以编辑 glance-api.conf 文件,并将 delayed_delete 选项设置为 False

20.5. 计算软删除功能

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

20.6. 裸机置备的安全强化

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

注意

如果可能,请考虑评估基于 Redfish 的 BMC。

20.7. 硬件识别

在部署服务器时,可能并不总是有可靠的方法将其与攻击者的服务器区分开来。这个功能可能取决于硬件/BMC 在某种程度上,但通常看似没有内置在服务器中识别的方法。

20.8. 数据加密

实施者存在用于加密项目数据的 选项,只要它存储在磁盘或通过网络传输,如下方所述的 OpenStack 卷加密功能。这高于一般建议,用户先加密自己的数据,然后再将其发送到供应商。

代表项目加密数据的重要性主要与攻击者可以访问项目数据的风险有关。政府可能满足要求,以及根据政策的要求、私人合同,甚至根据公共云提供商的私人合同要求。在选择项目加密策略前,请考虑获得风险评估和法律建议。

每个实例或每个对象加密可优先选择,以降序、每个项目、每个主机和每个云聚合。这个建议是针对实施的复杂性和难度。目前,对于某些项目,实施加密非常困难或根本不可能。实施者应考虑对项目数据进行加密的严重考虑。

通常,数据加密与可靠销毁项目和按实例数据的能力有关,只需丢弃密钥即可。应该注意,这样做非常重要,以可靠和安全的方式销毁这些密钥。

存在加密用户数据的机会:

  • Object Storage 对象
  • 网络数据

20.8.1. 卷加密

OpenStack 中的卷加密功能支持基于每个项目的隐私性。支持以下功能:

  • 创建和使用加密卷类型,通过仪表板或命令行界面启动
  • 启用加密并选择参数,如加密算法和密钥大小
  • iSCSI 数据包中包含的卷数据是加密的
  • 如果原始卷加密,支持加密的备份
  • 仪表板表示卷加密状态。包括表示卷已加密,并包含加密参数,如算法和密钥大小
  • 与密钥管理服务接口

20.8.2. Object Storage 对象

Object Storage (swift)支持在存储节点上对对象数据进行可选加密。对象数据的加密旨在降低在未经授权的方获得对磁盘的物理访问权限时读取用户数据的风险。

静态数据的加密由中间件实现,这些中间件可能包含在代理服务器 WSGI 管道中。该功能是 swift 集群内部,不通过 API 公开。客户端不知道数据由此功能在内部加密到 swift 服务;内部加密数据应该永远不会通过 swift API 返回给客户端。

在 swift 中剩余的数据时,以下数据会被加密:

  • 对象内容,如对象 PUT 请求正文的内容。
  • 具有非零内容的对象实体标签(ETag)。
  • 所有自定义用户对象元数据值。例如,使用带有 X-Object-Meta- 前缀的标头的 PUTPOST 请求发送元数据。

以上列表中未包含的任何数据或元数据都不会被加密,包括:

  • 帐户、容器和对象名称
  • 帐户和容器自定义用户元数据值
  • 所有自定义用户元数据名称
  • 对象 Content-Type 值
  • 对象大小
  • 系统元数据

20.8.3. 块存储性能和后端

在启用操作系统时,您可以使用 Intel 和 AMD 处理器中提供的硬件加速功能来提高 OpenStack 卷加密性能。

OpenStack 卷加密功能在主机上使用 dm-crypt 或原生 QEMU 加密支持来保护卷数据。红帽建议您在创建加密卷时使用 LUKS 卷加密类型。

20.8.4. 网络数据

Compute 节点的项目数据可以通过 IPsec 或其他隧道加密。这种做法在 OpenStack 中并不常见或标准,但可以选择动机和感兴趣的实施者。同样,加密的数据仍加密,因为它通过网络传输。

20.9. 密钥管理

为了解决项目数据隐私的常见关注,OpenStack 社区对数据加密有显著的兴趣,使数据加密更加广泛。最终用户在将数据保存到云之前,相对容易地加密其数据,而这是项目对象的可行路径,如介质文件、数据库存档等项目。在某些情况下,客户端加密用于加密由需要客户端交互(如提供密钥)的虚拟化技术持有的数据,以解密数据以供以后使用。

barbican 可以帮助项目更无缝地加密数据,并使其可访问,而不必给用户带来密钥管理负担。作为 OpenStack 的一部分提供加密和密钥管理服务,可简化数据的采用过程,并帮助解决客户对隐私性或数据的使用问题。

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

第 21 章 管理实例安全性

在虚拟化环境中运行实例的一个好处是安全控制的新机会,在部署到裸机时通常不可用。某些技术可以应用于虚拟化堆栈,从而改进了 OpenStack 部署的信息保证。具有强安全要求的 Operator 可能需要考虑部署这些技术,但并不适用于所有技术。在某些情况下,由于规范的业务需求,可能会排除在云中使用的技术。类似地,一些技术检查实例数据,如运行状态,这对系统的用户可能并不重要。

本章描述了这些技术,以及它们可用于帮助提高实例或底层节点的安全性的情况。可能的隐私性也被突出显示,其中可包括数据透传、内省或熵源。

21.1. 向实例提供熵

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

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

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

21.2. 将实例调度到节点

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

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

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

  • 基于资源的过滤器 - 根据虚拟机监控程序主机集的系统资源使用情况确定实例的放置,并可以在空闲或使用的属性(如 RAM、IO 或 CPU 使用率)上触发。
  • 基于镜像的过滤器 - 根据所使用的镜像元数据创建实例,如虚拟机的操作系统或所用镜像类型。
  • 基于环境过滤器 - 根据外部详情(如在特定 IP 范围内、可用性区域或与其他实例相同的主机上)确定实例的放置。
  • 自定义标准 - 根据用户或管理员提供标准(如信任或元数据解析)创建实例创建。

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

重要

考虑禁用解析用户提供的对象的过滤器,或者可以操作(如元数据)。

21.3. 使用可信镜像

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

21.4. 创建镜像

有关如何创建并将镜像上传到 Red Hat OpenStack Image 服务(glance)的指导,请参阅创建和管理镜像。将可信镜像用于您的环境以提高安全性,并使用机构的强化指南来进一步保护。您可以通过以下几种方法之一为您的环境获取镜像:

下载实例介质
要从可信源获取引导介质,请从官方红帽源下载镜像,并使用 SHA256SUM 进行验证。
从 ISO 创建镜像
有关从安装过程创建镜像的详情,请参考 创建 Red Hat Enterprise Linux 9 镜像
使用镜像构建器
您可以使用 disk-image-builder 生成在 OpenStack 中只有其用途所需的组件的最小系统。有关使用 disk-image-builder 创建自定义镜像的详情,请参考 生成自定义的 RHEL 系统镜像

21.5. 验证镜像签名

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

先决条件

  • 已安装 Red Hat OpenStack Platform director 环境。
  • 以 stack 身份登录 director。

流程

  1. 在 heat 模板中,通过将 True 的值设置为 VerifyGlanceSignatures 参数来启用实例签名验证:

    parameter_defaults:
        VerifyGlanceSignatures: True
    Copy to Clipboard Toggle word wrap
  2. 确保 openstack overcloud deploy 脚本中包含用于修改 VerifyGlanceSignatures 参数的模板,并重新运行 deploy 脚本。
注意

如果您使用未签名的镜像创建实例,则镜像会失败验证,实例也不会启动。有关对镜像进行签名的更多信息,请参阅 签署镜像服务镜像

21.6. 迁移实例

OpenStack 和底层虚拟化层为 OpenStack 节点之间的镜像实时迁移提供,允许您在不造成实例停机时间的情况下无缝地执行 Compute 节点的滚动升级。但是,实时迁移也会带来重大风险。要了解涉及的风险,以下是在实时迁移过程中执行的高级别步骤:

  1. 在目标主机上启动实例
  2. 转让内存
  3. 停止客户机和同步磁盘
  4. 传输状态
  5. 启动客户机
注意

某些操作(如冷迁移、调整大小和 shelve)可能会导致在网络上将实例的数据传送到其他服务等。

21.6.1. 实时迁移风险

在实时迁移过程的不同阶段,实例运行时间内存和磁盘的内容以纯文本通过网络传输。因此,在使用实时迁移时需要解决多个风险。以下非应对列表详细介绍了其中的一些风险:

  • 拒绝服务(DoS):在迁移过程中出现问题,则实例可能会丢失。
  • 数据暴露:必须安全处理内存或磁盘传输。
  • 数据操作:如果没有安全处理内存或磁盘传输,攻击者可以在迁移过程中操作用户数据。
  • 代码注入:如果没有安全处理内存或磁盘传输,攻击者可以在迁移过程中对可执行文件进行操作。

21.6.2. 禁用实时迁移

目前,OpenStack 中默认启用实时迁移。默认情况下,实时迁移是仅管理员的任务,因此用户无法启动此操作,而只有管理员(可能被信任)。可以通过在 nova policy.json 文件中添加以下行来禁用实时迁移:

"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",
Copy to Clipboard Toggle word wrap

或者,当阻止 TCP 端口 4915249261 时,实时迁移可能会失败,或者确保 nova 用户在计算主机之间没有免密码 SSH 访问。

请注意,实时迁移的 SSH 配置可显著锁定:创建新用户(nova_migration),并且 SSH 密钥仅限于该用户,并且仅在允许的网络上使用。然后,打包程序脚本会限制可运行的命令(例如,libvirt 套接字上的 netcat)。

21.6.3. 加密实时迁移

实时迁移流量以纯文本格式传输正在运行的实例的磁盘和内存内容,目前默认托管在内部 API 网络上。

如果有足够的要求(如升级)来保持实时迁移,则 libvirtd 可以为实时迁移提供加密的隧道。但是,此功能不会在 OpenStack Dashboard 或 nova-client 命令中公开,只能通过手动配置 libvirtd 来访问。然后,实时迁移过程会更改为以下高级别步骤:

  1. 实例数据从 hypervisor 复制到 libvirtd。
  2. 在源和目标主机上的 libvirtd 进程间创建一个加密的隧道。
  3. 目标 libvirtd 主机将实例复制到底层的虚拟机监控程序。
注意

对于 Red Hat OpenStack Platform 13,建议的方法是使用隧道迁移,该迁移在使用 Ceph 作为后端时默认启用。如需更多信息,请参阅 https://docs.openstack.org/nova/queens/configuration/config.html#libvirt.live_migration_tunnelled

21.7. 监控、警报和报告

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

注意

这些日志应定期检查,甚至应在网络操作中心(NOC)执行的实时视图中监控。

您需要进一步确定哪些事件将触发一个警报,该警报随后被发送到响应者以进行操作。

21.8. 更新和补丁

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

考虑将虚拟机的清除所有权分配给所有者,然后负责虚拟机的强化、部署和持续功能。您还应该有一个计划定期部署更新,而首次在类似于生产环境的环境中测试它们。

21.9. 防火墙和实例配置集

大多数常见操作系统包括基于主机的防火墙,以提供额外的安全层。虽然实例应尽可能少地运行(如果可能的话),但实例上运行的所有应用都应经过性能分析,以确定应用需要访问的系统资源、运行所需的最低权限级别以及预期的网络流量将来自虚拟机。此预期的流量应作为允许流量添加到基于主机的防火墙中,以及任何必要的日志记录和管理通信,如 SSH 或 RDP。所有其他流量都应该在防火墙配置中明确拒绝。

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

注意

Red Hat OpenStack Platform 默认启用 SELinux,以及针对 OpenStack 服务自定义的策略。根据需要,请考虑定期检查这些策略。

21.10. 安全组

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

注意

您应该保持安全组和端口安全性启用,除非您特别需要禁用它们。要基于 defense-depth 方法进行构建,建议您将粒度规则应用到实例。

21.11. 访问实例控制台

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

  • 考虑使用防火墙规则锁定 VNC 端口。默认情况下,nova_vnc_proxy 使用 608013080
  • 确认 VNC 流量由 TLS 加密。对于基于 director 的部署,以 UseTLSTransportForVnc 开始。

21.12. 证书注入

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

第 22 章 消息排队

消息排队服务有助于 OpenStack 中的进程间通信。这可以通过这些消息排队服务后端完成:

  • RabbitMQ - Red Hat OpenStack Platform 默认使用 RabbitMQ。
  • Qpid

RabbitMQ 和 Qpid 都是高级消息队列协议(AMQP)框架,它为对等通信提供消息队列。队列实施通常部署为队列服务器的集中式或分散池。

消息队列有效有助于命令和控制 OpenStack 部署之间的功能。允许访问队列后,不会执行进一步的授权检查。通过队列访问的服务来验证实际消息有效负载中的上下文和令牌。但是,您必须记下令牌的过期日期,因为令牌可能会重新显示,并可授权基础架构中其他服务。

OpenStack 不支持消息级的信任,如消息签名。因此,您必须保护并验证消息传输本身。对于高可用性(HA)配置,您必须执行队列到队列验证和加密。

22.1. 消息传递传输安全性

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

考虑为您的消息队列启用传输级别加密。使用 TLS 进行消息传递客户端连接可为通信提供保护,防止通信被篡改并转至消息传递服务器。以下提供了关于如何为两个流行消息传递服务器配置 TLS 的指导信息: Qpid 和 RabbitMQ。当配置您的消息传递服务器用来验证客户端连接的可信证书颁发机构(CA)捆绑包时,建议将此限制为用于节点的 CA,最好是内部管理的 CA。可信 CA 的捆绑包将决定哪个客户端证书将被授权并传递设置 TLS 连接的客户端验证步骤。

注意

安装证书和密钥文件时,请确保文件权限受限,例如使用 chmod 0600,并且所有权仅限于消息传递服务器守护进程用户,以防止由消息传递服务器上的其他进程和用户进行未授权的访问。

22.1.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}]}
   ]}
].
Copy to Clipboard Toggle word wrap
注意

tcp_listeners 选项设为 [],以防止它侦听非 SSL 端口。ssl_listeners 选项应限制为仅侦听该服务的管理网络。

22.2. 队列身份验证和访问控制

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

22.3. 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
Copy to Clipboard Toggle word wrap
注意

RABBIT_PASS 替换为合适的密码。

22.4. 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
Copy to Clipboard Toggle word wrap
注意

使用合适的密码替换 QPID_PASS

另外,如果将 SASL 与 Qpid 搭配使用,则可通过添加来指定正在使用的 SASL 机制:

qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>
Copy to Clipboard Toggle word wrap

22.5. 消息队列进程隔离和策略

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

消息队列服务进程应相互隔离,并且计算机中的其他进程与其他进程隔离。

22.6. 命名空间

Linux 使用命名空间将进程分配到独立域。本指南的其他部分更详细地描述了系统划分。

第 23 章 保护 Red Hat OpenStack Platform 中的端点

与 OpenStack 云互动的过程从查询 API 端点开始。虽然公共和私有端点存在不同的挑战,但这些资产在被破坏时可能会产生大量风险。

本章推荐对公共和私有的 API 端点进行安全增强。

23.1. 内部 API 通信

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

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

23.2. 在 Identity service 目录中配置内部 URL

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

考虑将配置的端点与网络级别隔离,因为它们具有不同的访问权限级别。Admin 端点供云管理员访问,因为它提供对内部或公共端点上不可用的 keystone 操作的升级访问权限。内部端点设计为使用云内部(如 OpenStack 服务),并且通常无法在部署网络外访问。公共端点应启用 TLS,并且部署外唯一可以访问的 API 端点,供云用户操作。

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

23.3. 为内部 URL 配置应用程序

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

每个项目可能会在定义目标 API 端点时产生不一致的方式。OpenStack 的未来发行版本寻求通过一致地使用 Identity 服务目录来解决这些不一致的问题。

23.4. 粘贴和中间件

OpenStack 中的大多数 API 端点和其他 HTTP 服务都使用 Python Paste Deploy 库。从安全的角度来看,此库允许通过应用程序的配置操作请求过滤器管道。此链中的每一元素称为中间件。更改管道中的过滤器顺序或添加额外的中间件可能会导致安全影响无法预测。

通常,实施者增加了中间件来扩展 OpenStack 的基本功能。考虑仔细考虑在 HTTP 请求管道中添加非标准软件组件所引入的潜在风险。

23.5. API 端点进程隔离和策略

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

23.5.1. 配置策略来限制 metadef API

在 Red Hat OpenStack Platform (RHOSP)中,用户可以使用元数据定义(metadef) API 来定义键值对和标签元数据。目前,用户可以创建的 metadef 命名空间、对象、属性、资源或标签数量没有限制。

metadef API 可能会将信息泄漏到未授权的用户。恶意用户可以利用缺乏限制,并用无限资源填充镜像服务(glance)数据库,从而创建拒绝的服务(DoS)风格攻击。

镜像服务策略控制 metadef API。但是,metadef API 的默认策略设置允许所有用户创建或读取 metadef 信息。由于 metadef 资源不与所有者隔离,因此具有潜在敏感名称(如内部基础架构详细信息或客户名称)的元数据资源可能会向恶意用户公开该信息。

要使镜像服务(glance)更安全,请在 Red Hat OpenStack Platform (RHOSP)部署中默认将 metadef 修改 API 限制为 admin-only 访问。

流程

  1. 作为云管理员,创建单独的 heat 模板环境文件,如 lock-down-glance-metadef-api.yaml,使其包含镜像服务 metadef API 的策略覆盖:

    ...
    parameter_defaults:
      GlanceApiPolicies: {
            glance-metadef_default: { key: 'metadef_default', value: '' },
            glance-metadef_admin: { key: 'metadef_admin', value: 'role:admin' },
            glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
            glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
            glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_admin' },
            glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_admin' },
            glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_admin' },
            glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
            glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
            glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_admin' },
            glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_admin' },
            glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_admin' },
            glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
            glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
            glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_admin' },
            glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_admin' },
            glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
            glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
            glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_admin' },
            glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_admin' },
            glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_admin' },
            glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
            glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
            glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_admin' },
            glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_admin' },
            glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_admin' },
            glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_admin' },
            glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_admin' }
      }
    
    …
    Copy to Clipboard Toggle word wrap
  2. 在部署 overcloud 时,在部署命令中包含策略覆盖的环境文件,使用 -e 选项:

    $ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml
    Copy to Clipboard Toggle word wrap

23.5.2. 启用 metadef API

如果您之前限制的元数据定义(metadef) API 或想要重新放置新默认值,您可以覆盖 metadef 修改策略,以允许用户更新其相应资源。

重要

具有依赖于写入 metadef API 访问权限的用户的云管理员可以使所有用户都可以访问这些 API。但是,在这种配置中,可能会意外泄漏敏感资源名称,如客户名称和内部项目。管理员必须审核其系统,以识别之前创建的资源可能存在安全漏洞,即使所有用户只启用了读取访问权限。

流程

  1. 作为云管理员,登录 undercloud 并为策略覆盖创建一个文件。例如:

    $ cat open-up-glance-api-metadef.yaml
    Copy to Clipboard Toggle word wrap
  2. 配置策略覆盖文件,以允许 metadef API 对所有用户进行读写访问:

    GlanceApiPolicies: {
        glance-metadef_default: { key: 'metadef_default', value: '' },
        glance-get_metadef_namespace: { key: 'get_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_namespaces: { key: 'get_metadef_namespaces', value: 'rule:metadef_default' },
        glance-modify_metadef_namespace: { key: 'modify_metadef_namespace', value: 'rule:metadef_default' },
        glance-add_metadef_namespace: { key: 'add_metadef_namespace', value: 'rule:metadef_default' },
        glance-delete_metadef_namespace: { key: 'delete_metadef_namespace', value: 'rule:metadef_default' },
        glance-get_metadef_object: { key: 'get_metadef_object', value: 'rule:metadef_default' },
        glance-get_metadef_objects: { key: 'get_metadef_objects', value: 'rule:metadef_default' },
        glance-modify_metadef_object: { key: 'modify_metadef_object', value: 'rule:metadef_default' },
        glance-add_metadef_object: { key: 'add_metadef_object', value: 'rule:metadef_default' },
        glance-delete_metadef_object: { key: 'delete_metadef_object', value: 'rule:metadef_default' },
        glance-list_metadef_resource_types: { key: 'list_metadef_resource_types', value: 'rule:metadef_default' },
        glance-get_metadef_resource_type: { key: 'get_metadef_resource_type', value: 'rule:metadef_default' },
        glance-add_metadef_resource_type_association: { key: 'add_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-remove_metadef_resource_type_association: { key: 'remove_metadef_resource_type_association', value: 'rule:metadef_default' },
        glance-get_metadef_property: { key: 'get_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_properties: { key: 'get_metadef_properties', value: 'rule:metadef_default' },
        glance-modify_metadef_property: { key: 'modify_metadef_property', value: 'rule:metadef_default' },
        glance-add_metadef_property: { key: 'add_metadef_property', value: 'rule:metadef_default' },
        glance-remove_metadef_property: { key: 'remove_metadef_property', value: 'rule:metadef_default' },
        glance-get_metadef_tag: { key: 'get_metadef_tag', value: 'rule:metadef_default' },
        glance-get_metadef_tags: { key: 'get_metadef_tags', value: 'rule:metadef_default' },
        glance-modify_metadef_tag: { key: 'modify_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tag: { key: 'add_metadef_tag', value: 'rule:metadef_default' },
        glance-add_metadef_tags: { key: 'add_metadef_tags', value: 'rule:metadef_default' },
        glance-delete_metadef_tag: { key: 'delete_metadef_tag', value: 'rule:metadef_default' },
        glance-delete_metadef_tags: { key: 'delete_metadef_tags', value: 'rule:metadef_default' }
      }
    Copy to Clipboard Toggle word wrap
    注意

    您必须将所有 metadef 策略配置为使用 rule:metadeta_default

  3. 在部署 overcloud 时,将新策略文件包含在部署命令中,并使用 -e 选项:

    $ openstack overcloud deploy -e open-up-glance-api-metadef.yaml
    Copy to Clipboard Toggle word wrap

23.6. 更改 HAProxy 的 SSL/TLS 密码和规则

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

  1. 创建名为 tls-ciphers.yaml 的 heat 模板环境文件:

    touch ~/templates/tls-ciphers.yaml
    Copy to Clipboard Toggle word wrap
  2. 使用环境文件中的 ExtraConfig hook 将值应用到 tripleo::haproxy::ssl_cipher_suitetripleo::haproxy::ssl_options hieradata:

    parameter_defaults:
      ExtraConfig:
        tripleo::haproxy::ssl_cipher_suite:: `DHE-RSA-AES128-CCM:DHE-RSA-AES256-CCM:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305`
    
        tripleo::haproxy::ssl_options:: no-sslv3 no-tls-tickets
    Copy to Clipboard Toggle word wrap
    注意

    cipher 集合是一个连续行。

  3. 在部署 overcloud 时,使用 overcloud deploy 命令包含 tls-ciphers.yaml 环境文件:

    openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/tls-ciphers.yaml
    ...
    Copy to Clipboard Toggle word wrap

23.7. 网络策略

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

经过仔细建模,您可以使用网络 ACL 和 IDS 技术在网络服务之间实施明确的点对点通信。作为关键的跨域服务,这种类型的显式执行非常适合 OpenStack 的消息队列服务。

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

23.8. 强制访问控制

您应该将 API 端点进程相互隔离,并在计算机上隔离其他进程。这些进程的配置应该通过 Discretionary Access Controls (DAC)和强制访问控制(MAC)来限制这些进程。这些增强的访问控制的目的是帮助 API 端点安全漏洞包含。

23.9. API 端点速率限制

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

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

在配置和实施任何速率限制功能时,操作员要仔细地规划并考虑 OpenStack 云中用户和服务的性能需求。

注意

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

第 24 章 实施联邦

警告

红帽目前不支持联邦。此功能只应用于测试,不应在生产环境中部署。

24.1. 使用红帽单点登录与 IdM 联合

您可以使用红帽单点登录(RH-SSO)来联合您的 IdM 用户进行 OpenStack 身份验证(authN)。联邦允许您的 IdM 用户登录 OpenStack 仪表板,而无需向任何 OpenStack 服务显示其凭证。相反,当 Dashboard 需要用户的凭证时,它会将用户转发到 Red Hat Single Sign-On (RH-SSO),并允许用户在其中输入其 IdM 凭证。因此,RH-SSO 认为用户已成功进行身份验证的 Dashboard,然后允许用户访问项目。

在下图中,keystone (SP)与 RH-SSO[id=the-federation-workflow_implementing-federation] = 联邦工作流通信

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

身份提供程序 (IdP)- 存储用户帐户的服务。在本例中,IdM 中保存的用户帐户使用 RH-SSO 向 Keystone 提供。

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

在下图中,keystone (SP)与 RH-SSO ( IdP)通信,它也可以充当其他 IdP 的通用适配器。在此配置中,您可以在 RH-SSO 上点 keystone,并且 RH-SSO 会将请求转发到它支持的身份提供程序(称为身份验证模块),这些目前包含 IdM 和 Active Directory。这通过将服务提供商(SP)和身份提供程序(IdP)交换元数据完成,然后每个系统管理员都做出信任决定。结果是 IdP 可以自信地进行断言,然后 SP 可以接收这些断言。

法律通告

版权所有 © 2017 Red Hat, Inc.
本文档内容及图解由红帽根据 Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA")授权。http://creativecommons.org/licenses/by-sa/3.0/ 中提供了CC-BY-SA 的说明。根据 CC-BY-SA,如果发布本文档或提供此文档,则必须提供原始版本的 URL。
作为本文档的许可者,红帽可能会放弃强制制执行 CC-BY-SA 第4d 条款,且不声明该条款在适用条款允许的最大限度内有效。
OpenStack 安全指南中采用的部分内容。请参阅 Red Hat OpenStack Platform Licenses 中的"安全指南"文档
Red Hat、Red Hat Enterprise Linux、Shadowman 徽标、JBoss、MetaMatrix、Fedora、Infinity 徽标和 RHCE 是 Red Hat, Inc. 在美国和其他国家/地区注册的商标。
Linux® 是 Linus Torvalds 在美国和其它国家的注册商标。
Java® 是 Oracle 和/或其附属公司注册的商标。
XFS® 是 Silicon Graphics International Corp. 或其子公司在美国和/或其他国家的商标。
MySQL® 是 MySQL AB 在美国、美国和其他国家注册的商标。
Node.js® 是 Joyent 的官方商标。Red Hat Software Collections 与官方 Joyent Node.js 开源或商业项目没有正式关联或被正式认可。
OpenStack® Word Mark 和 OpenStack 标识是 OpenStack Foundation 在美国和其他国家/地区注册商标/服务标记或商标/服务标记,适用于 OpenStack Foundation 的权限。我们不附属于 OpenStack Foundation 或 OpenStack 社区。
所有其他商标均由其各自所有者所有。
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。 了解我们当前的更新.

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

Theme

© 2025 Red Hat