安全和强化指南
最佳实践、合规性和安全强化
摘要
第 1 章 安全性简介 复制链接链接已复制到粘贴板!
使用 Red Hat Openstack Platform (RHOSP)提供的工具在规划和操作中优先考虑安全性,以满足用户对隐私性和数据安全性的期望。未能实施安全标准会导致停机或数据泄露。您的用例可能会受需要传递审计和合规性流程的法律。
- 有关强化 Ceph 的信息,请参阅 数据安全性和强化指南。
按照本指南中的说明来强化您的环境的安全性。但是,这些建议不能保证安全性或合规性。您必须根据环境的唯一要求评估安全性。
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
openstack network create internal-network
admin
用户可以通过使用-- project
参数在任意项目中创建 internal-network
:
openstack network create internal-network --project testing
openstack network create internal-network --project testing
1.3. 识别 Red Hat OpenStack Platform 中的安全区 复制链接链接已复制到粘贴板!
安全区是共享常见安全问题的资源、应用、网络和服务器。设计安全区,以便具有常见的身份验证和授权要求和用户。您可以根据云的架构、环境中可接受的信任级别以及机构的标准化要求,自行定义自己的安全区(如需要精细的安全区)。区域及其信任要求可能会因云实例是公共、私有还是混合而异。
例如,您可以将 Red Hat OpenStack Platform 的默认安装划分为以下区:
区 | 网络 | 详情 |
---|---|---|
公开 | 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。
流程
源
stackrc
:source /home/stack/stackrc
$ source /home/stack/stackrc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
openstack subnet list
,将分配的 ip 网络与其关联的区匹配:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
openstack server list
以列出您基础架构中的物理服务器:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用
openstack server list
命令中的ctlplane
地址查询物理节点的配置:ssh tripleo-admin@192.168.101.15 ip addr
ssh tripleo-admin@192.168.101.15 ip addr
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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。
流程
-
在 undercloud 节点上,以
tripleo-admin
用户身份通过 SSH 登录 overcloud 节点。 -
通过
sudo -i
切换到root
用户。
2.2. 将服务添加到 overcloud 防火墙 复制链接链接已复制到粘贴板!
部署 Red Hat OpenStack Platform 时,每个核心服务都会在每个 overcloud 节点上使用一组默认的防火墙规则进行部署。您可以使用 ExtraFirewallRules
参数创建规则来打开其他服务的端口,或者创建规则来限制服务。
每个规则名称都会成为相应 iptables
规则的注释。每个规则名称以三位前缀开头,以帮助 Puppet 在最终的 iptables
文件中对规则进行排序。默认 Red Hat OpenStack Platform 规则使用 000 中的前缀为 200 范围。为新服务创建规则时,请为名称添加大于 200 的三位数字前缀。
流程
使用字符串在
ExtraFireWallRules
参数下定义每个规则名称。您可以使用规则名称下的以下参数来定义规则:- dport :与规则关联的目的地端口。
-
Proto:: 与规则关联的协议。默认为
tcp
。 -
action:: 与规则关联的操作策略。默认为
accept
。 Source:: 与规则关联的源 IP 地址。
以下示例演示了如何使用规则为自定义应用程序打开其他端口:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果没有设置
action
参数,则结果将接受
。您只能将action
参数设置为drop
,insert
, 或append
。
在
openstack overcloud deloy
命令中包含~/templates/firewall.yaml
文件。包括部署所需的所有模板:openstack overcloud deploy --templates / ... -e /home/stack/templates/firewall.yaml / ....
openstack overcloud deploy --templates / ... -e /home/stack/templates/firewall.yaml / ....
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. 从 overcloud 防火墙中删除服务 复制链接链接已复制到粘贴板!
您可以使用规则来限制服务。您在规则名称中使用的数字决定了将插入规则的 iptables
中的位置。以下步骤演示了如何将 rabbitmq
服务限制为 InternalAPI 网络。
流程
在 Controller 节点上,查找
rabbitmq
的默认iptables
规则数量:sudo iptables -L | grep rabbitmq
[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 Copied! Toggle word wrap Toggle overflow 在环境文件 uder
parameter_defaults
中,使用ExtraFirewallRules
参数将rabbitmq
限制到 InternalApi 网络。该规则的编号低于默认的rabbitmq
规则编号或 109 :Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意如果没有设置
action
参数,则结果将接受
。您只能将action
参数设置为drop
,insert
, 或append
。在
openstack overcloud deloy
命令中包含~/templates/firewall.yaml
文件。包括部署所需的所有模板:openstack overcloud deploy --templates / ... -e /home/stack/templates/firewall.yaml / ....
openstack overcloud deploy --templates / ... -e /home/stack/templates/firewall.yaml / ....
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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
parameter_defaults:
ExtraConfig:
snmp::ro_community: mysecurestring
snmp::ro_community6: myv6securestring
这会改变所有节点上的只读 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"]
parameter_defaults:
ExtraConfig:
snmp::com2sec: ["notConfigUser default mysecurestring"]
snmp::com2sec6: ["notConfigUser default myv6securestring"]
这会改变所有节点上的只读 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
NeutronOVSFirewallDriver: openvswitch
-
NeutronOVSFirewallDriver
:配置要在实施安全组时使用的防火墙驱动程序的名称。可能的值取决于您的系统配置。某些示例包括noop
、openvswitch
和iptables_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 配置文件。
流程
检查您的部署的现有模板,以查找用于指定当前正在使用的角色的文件。在您的环境中使用的每个角色都有一个 NIC 配置文件。在以下示例中,RHOSP 环境包括
ComputeHCI
角色、Compute
角色和Controller
角色:Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHOSP 环境的每个角色执行许多相互相关的服务。您可以通过检查
roles
文件来记录各个角色使用的服务。如果为您的模板生成了一个
roles
文件,您可以在~/templates
目录中找到该文件:cd ~/templates find . -name *role* ./templates/roles_data_hci.yaml
$ cd ~/templates $ find . -name *role* > ./templates/roles_data_hci.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 如果没有为您的模板生成
roles
文件,您可以为当前用于检查文档的角色生成一个角色:openstack overcloud roles generate \ --roles-path /usr/share/openstack-tripleo-heat-templates/roles \ -o roles_data.yaml Controller Compute
$ openstack overcloud roles generate \ > --roles-path /usr/share/openstack-tripleo-heat-templates/roles \ > -o roles_data.yaml Controller Compute
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.2. 创建硬件清单 复制链接链接已复制到粘贴板!
您可以通过查看内省期间收集的数据来检索 Red Hat OpenStack Platform 部署的硬件信息。内省从节点收集 CPU、内存、磁盘等硬件信息。
先决条件
- 已安装 Red Hat OpenStack Platform director 环境。
- 您已为 Red Hat OpenStack Platform 部署内省节点。
- 以 stack 身份登录 director。
流程
从 undercloud 中,提供
stackrc
文件:source ~/stackrc
$ source ~/stackrc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 列出环境中的节点:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 对于从其收集信息的每个裸机节点,并运行以下命令来检索内省数据:
openstack baremetal introspection data save <node> | jq
$ openstack baremetal introspection data save <node> | jq
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<node
> 替换为在第 1 步中检索的列表中的节点名称。可选: 要将输出限制为特定类型的硬件,您可以检索清单密钥列表并查看特定密钥的内省数据:
运行以下命令,从内省数据获取顶层密钥列表:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 选择一个键,如
disks
,并运行以下命令以获取更多信息:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.3. 创建软件清单 复制链接链接已复制到粘贴板!
在 Red Hat OpenStack Platform (RHOSP)基础架构中部署的节点上记录使用的软件组件。在评估库、应用程序或软件类中威胁或漏洞的影响时,系统数据库、RHOSP 软件服务和支持组件(如负载均衡器、DNS 或 DHCP 服务)至关重要。
- 已安装 Red Hat OpenStack Platform 环境。
- 以 stack 身份登录 director。
流程
确定您知道可能受到恶意活动影响的系统和服务的入口点。在 undercloud 上运行以下命令:
cat /etc/hosts source stackrc ; openstack endpoint list source overcloudrc ; openstack endpoint list
$ cat /etc/hosts $ source stackrc ; openstack endpoint list $ source overcloudrc ; openstack endpoint list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHOSP 部署到容器化服务中,因此您可以通过检查该节点上运行的容器来查看 overcloud 节点上的软件组件。使用
ssh
连接到 overcloud 节点并列出正在运行的容器。例如,若要查看compute-0
上的 overcloud 服务,请运行类似如下的命令:ssh tripleo-admin@compute-0 podman ps
$ ssh tripleo-admin@compute-0 podman ps
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 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。
参数 | 描述 |
| 启用此选项要求用户在创建用户时或管理重置时更改密码。 |
| 在被视为"主动"并自动禁用(锁定)前,用户可以经过验证的最大天数。 |
|
超过用户帐户的失败尝试次数上限(如 |
|
在 |
| 在用户可以更改密码之前必须使用密码的天数。这可防止用户立即更改密码,以擦除密码历史记录并重复使用旧密码。 |
| 在要求用户更改密码之前,密码被视为有效的天数。 |
| 用于验证密码强度要求的正则表达式。 |
| 以人员使用的语言描述您的密码正则表达式。 |
| 这将控制在历史记录中保留的之前用户密码迭代的数量,以便强制新创建的密码是唯一的。 |
4.3.1. 使用 Identity service heat 参数停止无效的登录尝试 复制链接链接已复制到粘贴板!
重复失败的登录尝试可能是尝试进行暴力攻击的签名。在重复登录尝试失败后,您可以使用 Identity Service 限制对帐户的访问。
先决条件
- 已安装 Red Hat OpenStack Platform director 环境。
- 以 stack 身份登录 director。
流程
要配置用户可以在用户帐户锁定前验证的次数上限,请在环境文件中设置
KeystoneLockoutFailureAttempts
和KeystoneLockoutDuration
heat 参数的值。在以下示例中,KeystoneLockoutDuration
设置为 1 小时:parameter_defaults KeystoneLockoutDuration: 3600 KeystoneLockoutFailureAttempts: 3
parameter_defaults KeystoneLockoutDuration: 3600 KeystoneLockoutFailureAttempts: 3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在部署脚本中包含 环境文件。当您在之前部署的环境中运行部署脚本时,会使用附加参数进行更新:
openstack overcloud deploy --templates \ ... -e keystone_config.yaml ...
openstack overcloud deploy --templates \ ... -e keystone_config.yaml ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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。
第 5 章 使用 TLS 和 PKI 保护 Red Hat OpenStack 部署 复制链接链接已复制到粘贴板!
Red Hat OpenStack Platform 由多个网络和端点组成,它们处理您可以保护的敏感或机密数据。使用传输层安全(TLS)时,您可以使用对称密钥加密保护流量。密钥和证书在 TLS 握手中协商,这需要在称为证书颁发机构(CA)的中间通过共享信任来验证服务器的身份。
公钥基础架构(PKI)是一种框架,用于通过证书颁发机构验证实体。
5.1. 公钥基础架构组件(PKI) 复制链接链接已复制到粘贴板!
PKI 的核心组件在下表中显示:
术语 | 定义 |
---|---|
结束实体 | 使用数字证书验证自己的用户、进程或系统。 |
证书颁发机构(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
运行密码扫描:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
在扫描服务器时,Cipherscan 公告对特定的 TLS 版本的支持,这是它要协商的最高 TLS 版本。如果目标服务器正确遵循 TLS 协议,它将以相互支持的最高版本响应,这可能低于最初公告的 Cipherscan。如果服务器继续使用该特定版本与客户端建立连接,则不被视为接受该协议版本。如果没有建立连接(使用指定的版本或任何较低版本),则考虑存在该版本的协议的容限。例如:
在这个输出中,TLS 1.0
和 TLS 1.1
的不容限被报告为 PRESENT
,这意味着无法建立连接,并且 Cipherscan 在广告支持时无法连接。因此,最好在扫描的服务器上不启用协议的那些(以及较低版本)的协议。
5.4. OpenStack 的身份管理(IdM)服务器建议 复制链接链接已复制到粘贴板!
红帽提供了以下信息,可帮助您集成 IdM 服务器和 OpenStack 环境。
有关为 IdM 安装准备 Red Hat Enterprise Linux 的详情,请参考 安装身份管理。
运行 ipa-server-install
命令以安装和配置 IdM。您可以使用命令参数跳过交互式提示。使用以下建议,以便您的 IdM 服务器可以与 Red Hat OpenStack Platform 环境集成:
选项 | 建议 |
---|---|
| 请注意您提供的值。在配置 Red Hat OpenStack Platform 以使用 IdM 时,您将需要此密码。 |
| 请注意您提供的值。undercloud 和 overcloud 节点需要网络访问此 ip 地址。 |
| 使用这个选项在 IdM 服务器上安装集成的 DNS 服务。undercloud 和 overcloud 节点使用 IdM 服务器进行域名解析。 |
|
使用这个选项使用 |
| 使用这个选项解析 IdM 服务器 IP 地址的反向记录和区域。如果反向记录或区域都无法解析,IdM 会创建反向区域。这简化了 IdM 部署。 |
| 您可以使用这些选项或其中任一个来配置 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 install
和 openstack overcloud deploy
等命令。这些过程是幂等的,仅调整您现有的部署配置,以匹配更新的模板和配置文件。
配置
/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
search example.com bigcorp.com nameserver $IDM_SERVER_IP_ADDR
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 安装所需的软件:
sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
sudo dnf install -y python3-ipalib python3-ipaclient krb5-devel
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用特定于您的环境的值导出环境变量。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 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
ansible-playbook \ --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \ /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 undercloud.conf 中添加以下参数
undercloud_nameservers = $IDM_SERVER_IP_ADDR overcloud_domain_name = example.com
undercloud_nameservers = $IDM_SERVER_IP_ADDR overcloud_domain_name = example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow [可选] 如果您的 IPA 域与您的 IPA 域不匹配,请设置
certmonger_krb_realm
参数的值:在
/home/stack/hiera_override.yaml
中设置certmonger_krb_realm
的值:parameter_defaults: certmonger_krb_realm = EXAMPLE.COMPANY.COM
parameter_defaults: certmonger_krb_realm = EXAMPLE.COMPANY.COM
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
undercloud.conf
中的custom_env_files
参数的值设置为/home/stack/hiera_override.yaml
:custom_env_files = /home/stack/hiera_override.yaml
custom_env_files = /home/stack/hiera_override.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
部署 undercloud:
openstack undercloud install
openstack undercloud install
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
通过完成以下步骤验证 undercloud 是否已正确注册:
列出 IdM 中的主机:
kinit admin ipa host-find
$ kinit admin $ ipa host-find
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确认 undercloud 上是否存在
/etc/novajoin/krb5.keytab
。ls /etc/novajoin/krb5.keytab
ls /etc/novajoin/krb5.keytab
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
novajoin
目录名称仅用于传统的命名目的。
在 overcloud 上配置 TLS-e
当您使用 TLS (TLS-e)部署 overcloud 时,来自 Undercloud 和 Overcloud 的 IP 地址将自动注册到 IdM。
在部署 overcloud 之前,创建一个 YAML 文件
tls-parameters.yaml
,其内容类似于以下内容:您选择的值将特定于您的环境:Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
显示的
OS::TripleO::Services::IpaClient
参数的值覆盖enable-internal-tls.yaml
文件中的默认设置。您必须在openstack overcloud deploy
命令中确保tls-parameters.yaml
文件遵循enable-internal-tls.yaml
。 - 有关实现 TLS-e 的参数的更多信息,请参阅 tripleo-ipa 的参数。
-
显示的
部署 overcloud。您需要在部署命令中包含 tls-parameters.yaml :
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过查询 keystone 以获取端点列表来确认每个端点正在使用 HTTPS:
openstack endpoint list
openstack endpoint list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 :
创建名为
memcached.yaml
的环境文件,其中包含以下内容,以添加 memcached 的 TLS 支持:parameter_defaults: MemcachedTLS: true MemcachedPort: 11212
parameter_defaults: MemcachedTLS: true MemcachedPort: 11212
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 overcloud 部署过程中包含
memcached.yaml
环境文件:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
其它资源
- 有关使用 tripleo-ipa 部署 TLSe 的更多信息,请参阅使用 Ansible 实施 TLS-e。
5.8. 增加私钥的大小 复制链接链接已复制到粘贴板!
您可以通过增大用于为加密服务流量创建证书的私钥的大小来提高安全性。默认的 RHOSP 私钥大小为 2048 位,与国家标准与技术研究院(NIST)匹配。
-
使用
CertificateKeySize
参数来全局更改私钥大小。 -
使用特定于服务的参数,如
RedisCertificateKeySize
、修改特定私钥,或者覆盖全局CertificateKeySize
参数。
在环境 heat 模板中使用这些参数,并在 overcloud 部署命令中包含该模板。如果您已经部署了 overcloud,则必须使用您最初使用的同一模板重新运行相同的 openstack overcloud deploy
命令,并包含新参数以使更改生效。
在以下示例中,私钥的全局值为 4096
。redis
的私钥是 2048
,因为 RedisCertificateKeySize
会覆盖全局参数:
Example
parameter_defaults: CertificateKeySize: '4096' RedisCertificateKeySize: '2048'
parameter_defaults:
CertificateKeySize: '4096'
RedisCertificateKeySize: '2048'
5.9. 将 Red Hat OpenStack Platform 的 IdM 服务器替换为其副本 复制链接链接已复制到粘贴板!
当您将现有 IPA 服务器替换为其副本时,您必须更新必要的参数。如果不这样做,在更新集群的配置时会导致 overcloud 部署失败。
流程
在每个 overcloud 节点上,编辑
/etc/ipa/default.conf
配置文件,以确保server
和xmlrpc_uri
参数包含 IdM 服务器的完全限定域名(FQDN):Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 undercloud 上,编辑
/home/stack/templates/tls-parameters.yaml
环境文件,并确保IPA_SERVER_HOSTNAME
参数与/etc/ipa/default.conf
中的xmlrpc_uri
和 server 参数中显示的 FQDN 匹配。确保所有参数都与您的环境匹配:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 6 章 配置自定义 SSL/TLS 证书 复制链接链接已复制到粘贴板!
您可以手动将 undercloud 配置为使用 SSL/TLS 进行公共端点上的通信。使用 SSL/TLS 手动配置 undercloud 端点时,您要创建安全端点作为概念验证。红帽建议使用证书颁发机构解决方案。
当您使用证书颁发机构(CA)解决方案时,您已有生产环境的准备解决方案,如证书续订、证书撤销列表(CRL)和行业接受加密。有关使用 Red Hat Identity Manager (IdM)作为 CA 的信息,请参阅使用 Ansible 实施 TLS-e。
如果要将 SSL 证书与您自己的证书颁发机构一起使用,您必须完成以下配置步骤。
6.1. 初始化签名主机 复制链接链接已复制到粘贴板!
签名主机是使用证书颁发机构生成并签名新证书的主机。如果您从未在所选签名主机上创建 SSL 证书,您可能需要初始化该主机,让它能够为新证书签名。
流程
/etc/pki/CA/index.txt
文件包含所有签名证书的记录。请确定文件系统路径和index.txt
文件已存在:sudo mkdir -p /etc/pki/CA sudo touch /etc/pki/CA/index.txt
$ sudo mkdir -p /etc/pki/CA $ sudo touch /etc/pki/CA/index.txt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/pki/CA/serial
文件标识下一个序列号,以用于下一个要签名的证书。检查是否存在此文件。如果此文件不存在,则使用新启动值创建新文件:echo '1000' | sudo tee /etc/pki/CA/serial
$ echo '1000' | sudo tee /etc/pki/CA/serial
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.2. 创建证书颁发机构 复制链接链接已复制到粘贴板!
一般情况下,您需要使用一个外部的证书认证机构来签发您的 SSL/TLS 证书。在某些情况下,您可能想使用自己的证书颁发机构。例如,您可能想拥有仅限内部使用的证书颁发机构。
流程
生成密钥和证书对以充当证书颁发机构:
openssl genrsa -out ca.key.pem 4096 openssl req -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
$ 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 Copied! Toggle word wrap Toggle overflow -
openssl req
命令会要求输入认证机构的详细信息。根据提示输入相关信息。这些命令创建一个称为ca.crt.pem
的证书颁发机构文件。 在
enable-tls.yaml
文件中,将证书位置设置为PublicTLSCAFile
参数的值。当您将证书位置设置为PublicTLSCAFile
参数的值时,请确保将 CA 证书路径添加到clouds.yaml
身份验证文件中。parameter_defaults: PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem
parameter_defaults: PublicTLSCAFile: /etc/pki/ca-trust/source/anchors/cacert.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. 将此证书颁发机构添加到客户端 复制链接链接已复制到粘贴板!
对于旨在使用 SSL/TLS 通信的所有外部客户端,将证书颁发机构文件复制到需要访问 Red Hat OpenStack Platform 环境的每个客户端。
流程
将证书颁发机构复制到客户端系统:
sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将证书颁发机构文件复制到每个客户端后,在每个客户端上运行以下命令,将证书添加到证书颁发机构信任捆绑包中:
sudo update-ca-trust extract
$ sudo update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4. 创建 SSL/TLS 密钥 复制链接链接已复制到粘贴板!
在 OpenStack 环境中启用 SSL/TLS 需要一个 SSL/TLS 密钥来生成证书。
流程
运行以下命令以生成 SSL/TLS 密钥 (
server.key.pem
):openssl genrsa -out server.key.pem 2048
$ openssl genrsa -out server.key.pem 2048
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. 创建 SSL/TLS 证书签名请求 复制链接链接已复制到粘贴板!
完成以下步骤以创建证书签名请求。
流程
复制默认 OpenSSL 配置文件:
cp /etc/pki/tls/openssl.cnf .
$ cp /etc/pki/tls/openssl.cnf .
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑新的
openssl.cnf
文件并配置要用于 director 的 SSL 参数。一个要修改的参数类型的示例包括:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
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
命令。-
如果使用 IP 地址通过 SSL/TLS 访问 director,则使用
运行以下命令以生成证书签名请求 (
server.csr.pem
):openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 确保使用
-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
- 证书颁发机构私钥。
流程
如果尚未存在,请创建
newcerts
目录:sudo mkdir -p /etc/pki/CA/newcerts
sudo mkdir -p /etc/pki/CA/newcerts
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行以下命令,为 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
$ 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 Copied! Toggle word wrap Toggle overflow 这个命令使用以下选项:
-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 信任捆绑包中。
流程
运行以下命令以组合证书和密钥:
cat server.crt.pem server.key.pem > undercloud.pem
$ cat server.crt.pem server.key.pem > undercloud.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 此命令创建
undercloud.pem
文件。将
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
$ 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 Copied! Toggle word wrap Toggle overflow 将
undercloud.pem
文件位置添加到undercloud.conf
文件的undercloud_service_certificate
选项中:undercloud_service_certificate = /etc/pki/undercloud-certs/undercloud.pem
undercloud_service_certificate = /etc/pki/undercloud-certs/undercloud.pem
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 不要设置或启用
generate_service_certificate
和certificate_generation_ca
参数。director 使用这些参数自动生成证书,而不使用您手动创建的undercloud.pem
证书。将签名证书的证书颁发机构添加到 undercloud 的可信证书颁发机构列表中,以便 undercloud 内的不同服务能够访问证书颁发机构:
sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/ sudo update-ca-trust extract
$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/ $ sudo update-ca-trust extract
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 要验证证书颁发机构是否已添加到 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
$ 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 Copied! Toggle word wrap Toggle overflow 将
<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 证书和私钥的参数。
流程
从 heat 模板集合中复制
enable-tls.yaml
环境文件:cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 编辑此文件并为这些参数进行以下更改:
- SSLCertificate
将证书文件(
server.crt.pem
)的内容复制到SSLCertificate
参数中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要证书内容为所有新行需要相同的缩进级别。
- SSLIntermediateCertificate
如果您有中间证书,请将中间证书的内容复制到
SSLIntermediateCertificate
参数中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要证书内容为所有新行需要相同的缩进级别。
- SSLKey
将私钥(
server.key.pem
)的内容复制到SSLKey
参数中:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要私钥内容为所有新行需要相同的缩进级别。
7.2. 注入 root 证书 复制链接链接已复制到粘贴板!
如果证书签名者不在 overcloud 镜像上的默认信任存储中,您必须将证书颁发机构注入 overcloud 镜像。
流程
从 heat 模板集合中复制
inject-trust-anchor-hiera.yaml
环境文件:cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.
$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
编辑此文件并为这些参数进行以下更改:
- CAMap
列出要注入 overcloud 的每个证书颁发机构内容(CA)。overcloud 需要 CA 文件,用于为 undercloud 和 overcloud 签署证书。将 root 证书颁发机构文件(
ca.crt.pem
)的内容复制到条目。例如,您的CAMap
参数可能类似如下:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重要证书颁发机构内容为所有新行需要相同的缩进级别。
您还可以使用 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
-
如果您使用 DNS 名称访问公共端点,请使用
流程
- 使用以下部署命令片断作为如何包含 SSL/TLS 环境文件的示例:
7.5. 手动更新 SSL/TLS 证书 复制链接链接已复制到粘贴板!
如果您使用自己的 SSL/TLS 证书,这些证书不是随处 TLS 自动生成的(TLS-e)过程。
流程
使用以下内容编辑 heat 模板:
-
编辑
enable-tls.yaml
文件,并更新SSLCertificate
、SSLKey
和SSLIntermediateCertificate
参数。 -
如果您的证书颁发机构已更改,请编辑
inject-trust-anchor-hiera.yaml
文件并更新CAMap
参数。
-
编辑
重新运行部署命令:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 director 上,为每个 Controller 运行以下命令:
ssh tripleo-admin@<controller> sudo podman \ restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')
ssh tripleo-admin@<controller> sudo podman \ restart $(podman ps --format="{{.Names}}" | grep -w -E 'haproxy(-bundle-.*-[0-9]+)?')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 8 章 在 overcloud 中使用 Fernet 密钥进行加密 复制链接链接已复制到粘贴板!
Fernet 是默认的令牌提供程序,它取代 uuid
。您可以查看 Fernet 部署并轮转 Fernet 密钥。Fernet 使用三种类型的密钥,它们存储在 /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys
中。最高数字目录包含主密钥,它生成新的令牌并解密现有的令牌。
Fernet 密钥轮转使用以下过程:
- 主密钥成为辅助密钥。
- <system> 签发一个新的主密钥。轮转除的主密钥将不再有效。您可以使用辅助密钥解密与之前的主密钥关联的令牌,但您无法发布新的令牌。
当您决定 Fernet 密钥轮转周期的长度时,遵循您的组织的安全状况。如果您的组织没有指导,因为安全考虑,每月轮转周期是很好的做法。
8.1. 检查 Fernet 部署 复制链接链接已复制到粘贴板!
要测试 Fernet 令牌是否正常工作,请检索 Controller 节点的 IP 地址,SSH 到 Controller 节点,然后检查令牌驱动程序和提供程序的设置。
流程
检索 Controller 节点的 IP 地址:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow SSH 到 Controller 节点:
ssh tripleo-admin@192.0.2.16
[tripleo-admin@overcloud-controller-0 ~]$ ssh tripleo-admin@192.0.2.16
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检索令牌驱动程序和提供程序设置的值:
sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf token driver sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf token provider
[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 Copied! Toggle word wrap Toggle overflow 测试 Fernet 供应商:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 结果包括长的 Fernet 令牌。
8.2. 使用工作流服务轮转 Fernet 密钥 复制链接链接已复制到粘贴板!
为确保在堆栈更新后保持 Fernet 密钥,请使用 Workflow 服务(mistral)轮转密钥。默认情况下,director 使用 ManageKeystoneFernetKeys
参数在环境文件中管理 overcloud Fernet 密钥。Fernet 密钥存储在工作流服务中,KeystoneFernetKeys
部分中。
流程
查看现有的 Fernet 密钥:
确定 Fernet 密钥位置。以 tripleo-admin 用户身份登录 Controller 节点,并使用
crudini
命令查询 Fernet 密钥:sudo crudini --get /var/lib/config-data/puppet-generated/keystone/etc/keystone/keystone.conf fernet_tokens key_repository
[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 Copied! Toggle word wrap Toggle overflow 注意/etc/keystone/
目录引用容器文件系统路径。检查当前的 Fernet 密钥目录:
sudo ls /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys
[tripleo-admin@overcloud-controller-0 ~]$ sudo ls /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys 0 1 2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
0
- 包括 staged 密钥,它会变为下一个主密钥,并始终为0
。 -
1
- 包含辅助密钥。 2
- 包含主密钥。每次密钥轮转时,这个数字都会递增。最高数字始终用作主密钥。注意-
使用
max_active_keys
属性设置最大键数。默认值为 5 密钥。 - 密钥在所有 Controller 节点上传播。
-
使用
-
使用
workflow
命令轮转 Fernet 密钥:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
验证
检索 ID,并确保工作流成功。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在 Controller 节点上,检查 Fernet 密钥的数量,并与前面的结果进行比较。
sudo ls /var/lib/config-data/puppet-generated/keystone/etc/keystone/fernet-keys
[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 Copied! Toggle word wrap Toggle overflow -
0
- 包括 staged 密钥,始终为0
。这个密钥在下次轮转过程中成为主密钥。 -
1 和 2
- 包含辅助密钥。 3
- 包含主密钥。每次密钥轮转时,这个数字会递增。最高数字始终用作主密钥。注意-
使用
max_active_keys
属性设置最大键数。默认值为 5 密钥。 - 密钥在所有 Controller 节点上传播。
-
使用
-
第 9 章 Red Hat OpenStack Platform 上的联邦信息处理标准 复制链接链接已复制到粘贴板!
该功能在此发行版本中作为技术预览提供,因此不享有红帽的全面支持。它只应用于测试,不应部署在生产环境中。有关技术预览功能的更多信息,请参阅覆盖范围详细信息。
联邦信息处理标准(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。
流程
在 undercloud 上启用 FIPS:
在您要在其上安装 undercloud 的系统中启用 FIPS:
fips-mode-setup --enable
fips-mode-setup --enable
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意此步骤会将
fips=1
内核参数添加到 GRUB 配置文件中。因此,只有 Red Hat Enterprise Linux 使用的加密算法模块处于 FIPS 模式,且只使用标准批准的加密算法。- 重启系统:
验证是否启用了 FIPS:
fips-mode-setup --check
fips-mode-setup --check
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 安装和配置 Red Hat OpenStack Platform director。有关更多信息,请参阅: 在 undercloud 上安装 director。
为 overcloud 准备启用了 FIPS 的镜像。
为 overcloud 安装镜像:
sudo dnf -y install rhosp-director-images-uefi-fips-x86_64
sudo dnf -y install rhosp-director-images-uefi-fips-x86_64
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在
stack
用户的主目录中创建images
目录:mkdir /home/stack/images cd /home/stack/images
$ mkdir /home/stack/images $ cd /home/stack/images
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将镜像提取到您的主目录中:
for i in /usr/share/rhosp-director-images/*fips*.tar; do tar -xvf $i; done
for i in /usr/share/rhosp-director-images/*fips*.tar; do tar -xvf $i; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在上传镜像前,您必须创建符号链接:
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
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 Copied! Toggle word wrap Toggle overflow 将启用了 FIPS 的 overcloud 镜像上传到镜像服务:
openstack overcloud image upload --update-existing --whole-disk
openstack overcloud image upload --update-existing --whole-disk
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意即使 OpenStack 镜像服务中没有镜像,您也必须使用
--update-existing
标志。
在 overcloud 上启用 FIPS。
为特定于您的环境的 overcloud 部署配置模板。在部署命令中包含所有配置模板,包括 fips.yaml :
openstack overcloud deploy ... -e /usr/share/openstack-tripleo-heat-templates/environents/fips.yaml
openstack overcloud deploy ... -e /usr/share/openstack-tripleo-heat-templates/environents/fips.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 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 用户角色不会解决所有审计用例。
基于 system
或 domain
范围的额外人员正在开发中,还不可用。
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
openstack overcloud deploy --templates … -e /usr/share/openstack-tripleo-heat-templates/environments/enable-secure-rbac.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.3. 在 SRBAC 环境中分配角色 复制链接链接已复制到粘贴板!
使用 Red Hat OpenStack Platform 上的 SRBAC,您可以将用户分配给 project-admin
、project-member
或 project-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
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> admin
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 分配
member
角色:openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> member
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> member
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 分配
reader
角色:openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> reader
$ openstack role add --user <user> --user-domain <domain> --project <project> --project-domain <project-domain> reader
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
将
<user
> 替换为一个现有用户以应用该角色。 -
将
<
domain> 替换为角色应用到的域。 -
将
<
;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
podman exec -it keystone oslopolicy-policy-generator --namespace keystone
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
默认情况下,生成的策略通过 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"
"identity:create_user": "rule:admin_required"
字符左侧的部分描述了特权,以及右侧的部分来定义谁可以使用特权。
您还可以在右侧使用 Operator 来进一步控制范围:
-
!
- 无用户(包括 admin)都可以执行此操作。 -
@
和""
- Any 用户可以执行此操作。 -
not
,and
,or
- 可以使用标准的操作符。
例如,以下设置表示没有用户创建新用户的权限:
"identity:create_user": "!"
"identity:create_user": "!"
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
。
创建自定义 keystone 角色:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将现有用户添加到角色中,并为项目分配角色:
openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
$ openstack role add --project [PROJECT_NAME] --user [USER_ID] [PowerUsers-ROLE_ID]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意角色分配仅与一个项目配对。这意味着,当您为用户分配角色时,您也会同时定义 target 项目。如果您希望用户接收同一角色但针对不同的项目,则必须单独为它们分配角色,但以不同的项目为目标。
查看默认的 nova 策略设置:
oslopolicy-policy-generator --namespace nova
$ oslopolicy-policy-generator --namespace nova
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 通过将以下条目添加到
/var/lib/config-data/puppet-generated/nova/etc/nova/policy.json
,为新的PowerUsers
角色创建自定义权限:注意在部署前测试您的策略更改,以验证它们是否按预期工作。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在保存文件并重启 nova 容器时,您将实施这些更改。添加到
PowerUsers
keystone 角色的用户会收到这些特权。
11.5. 示例:根据属性限制访问 复制链接链接已复制到粘贴板!
红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。
您可以根据发出该 API 调用的用户属性,创建将限制对 API 调用的访问的策略。例如,以下默认规则指出,如果从管理上下文运行,或者令牌的用户 ID 与与目标关联的用户 ID 匹配,则允许密钥对删除。
"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"
"os_compute_api:os-keypairs:delete": "rule:admin_api or user_id:%(user_id)s"
注意:"新实施"功能无法保证在每个版本中都有相应的功能。因此,使用目标服务的现有策略惯例编写规则非常重要。有关查看这些策略的详情,请参阅查看现有策略。对于要部署它们的每个版本,所有策略都应该在非生产环境中测试,因为策略无法保证跨版本的兼容性。
根据上例,您可以制作 API 规则,根据是否拥有资源来限制用户访问权限。另外,属性可以与其他限制结合使用,以组成规则,如下例所示:
"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
"admin_or_owner": "is_admin:True or project_id:%(project_id)s"
考虑以上示例,您可以创建一个仅限于管理员和用户的唯一规则,然后使用该规则进一步限制操作:
"admin_or_user": "is_admin:True or user_id:%(user_id)s" "os_compute_api:os-instance-actions": "rule:admin_or_user"
"admin_or_user": "is_admin:True or user_id:%(user_id)s"
"os_compute_api:os-instance-actions": "rule:admin_or_user"
11.6. 使用 heat 修改策略 复制链接链接已复制到粘贴板!
红帽不支持自定义角色或策略。语法错误或错误应用授权可能会对安全性或可用性造成负面影响。如果在生产环境中需要自定义角色或策略,请联系红帽支持例外。
您可以使用 heat 为 overcloud 中的某些服务配置访问策略。使用以下参数在相应的服务上设置策略:
参数 | 描述 |
---|---|
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' } }
parameter_defaults: KeystonePolicies: { keystone-context_is_admin: { key: context_is_admin, value: 'role:admin' } }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenStack Compute (nova)使用
NovaApiPolicies
参数。在环境文件的parameter_defaults
部分中设置此参数:parameter_defaults: NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '@' } }
parameter_defaults: NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '@' } }
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.7. 审计您的用户和角色 复制链接链接已复制到粘贴板!
您可以使用 Red Hat OpenStack Platform 中提供的工具为每个用户和关联特权构建角色分配报告。
先决条件
- 已安装 Red Hat OpenStack Platform 环境。
- 以 stack 身份登录 director。
流程
运行
openstack role list
命令以查看环境中当前的角色:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 运行
openstack role assignment list
命令,以列出属于特定角色的所有用户。例如,要查看具有 admin 角色的所有用户,请运行以下命令:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以使用
-f {csv,json,table,value,yaml}
参数导出这些结果。
11.8. 审计 API 访问 复制链接链接已复制到粘贴板!
您可以审核给定角色可以访问的 API 调用。为每个角色重复此过程将导致全面报告每个角色可访问的 API。
先决条件
- 作为目标角色中的用户提供的身份验证文件。
- JSON 格式的访问令牌。
- 您要审计的每个服务 API 的策略文件。
流程
- 首先,在所需角色中提供用户的身份验证文件。
捕获 Keystone 生成的令牌并将其保存到文件中。您可以通过运行任何 openstack-cli 命令并使用 --debug 选项进行此操作,该选项会将提供的令牌输出到 stdout。您可以复制此令牌并将其保存到访问文件中。使用以下命令作为单一步骤执行此操作:
openstack token issue --debug 2>&1 | egrep ^'{\"token\":' > access.file.json
openstack token issue --debug 2>&1 | egrep ^'{\"token\":' > access.file.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 创建策略文件。这可以在托管相关容器化服务的 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
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 Copied! Toggle word wrap Toggle overflow 使用这些文件,您现在可以审核相关角色以访问 Cinder 的 API:
oslopolicy-checker --policy cinderpolicy.json --access access.file.json
oslopolicy-checker --policy cinderpolicy.json --access access.file.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
第 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 复制链接链接已复制到粘贴板!
当您添加用于云环境中的硬件时,请确保支持硬件虚拟化。禁用不使用的硬件功能。
流程
- 检查 Red Hat OpenStack 认证的硬件,以确保您的硬件受支持。
检查硬件虚拟化是否可用并启用:
cat /proc/cpuinfo | egrep "vmx|svm"
cat /proc/cpuinfo | egrep "vmx|svm"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 确保所有固件在硬件平台上都处于最新状态。详情请查看硬件供应商文档。
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
$ sudo podman inspect <container_name> | less
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将 <container_name> 替换为容器的名称。例如,
nova 计算
。检查位于
/var/log/containers
中的服务的日志:例如:
sudo less /var/log/containers/nova/nova-compute.log
sudo less /var/log/containers/nova/nova-compute.log
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在容器内运行交互式 CLI 会话:
例如:
podman exec -it nova_compute /bin/bash
podman exec -it nova_compute /bin/bash
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您可以对服务进行更改,以直接在容器中测试目的。容器重启时,所有更改都会丢失。
13.6. 对容器化服务进行临时更改 复制链接链接已复制到粘贴板!
您可以对容器重启时保留的容器化服务进行更改,但不会影响 Red Hat OpenStack Platform (RHOSP)集群的永久配置。这可用于测试配置更改,或者在故障排除时启用调试级别的日志。您可以手动恢复更改。或者,在 RHOSP 集群中运行的重新部署会将所有参数重置为其永久配置。
使用位于 /var/lib/config-data/puppet-generated/[service]
的配置文件,对服务进行临时更改。以下示例在 nova 服务中启用调试:
流程
编辑绑定至
nova_compute
容器的nova.conf
配置文件。将debug
参数的值设置为True
:sudo sed -i 's/^debug=.*/debug=True' \ /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf
$ sudo sed -i 's/^debug=.*/debug=True' \ /var/lib/config-data/puppet-generated/nova/etc/nova/nova.conf
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 警告OpenStack 文件的配置文件是
ini
文件,其中包括多个部分,如[DEFAULT]
和[database]
。在整个文件中,每个部分独有的参数可能并不唯一。请谨慎使用sed
。您可以通过运行egrep -v "^$|^#" [configuration_file] | grep [parameter]
以检查一个参数
是否在配置文件中出现了多次。重启 nova 容器:
sudo podman restart nova_compute
sudo podman restart nova_compute
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.7. 对容器化服务进行永久更改 复制链接链接已复制到粘贴板!
您可以使用 heat 对 Red Hat OpenStack Platform (RHOSP)服务中的容器化服务进行永久更改。使用您在首次部署 RHOSP 时使用的现有模板,或创建新模板来添加到部署脚本中。在以下示例中,libvirt 的私钥大小增加到 4096
。
流程
创建一个名为
libvirt-keysize.yaml
的新yaml
模板,并使用LibvirtCertificateKeySize
参数将默认值从2048
增加到4096
。cat > /home/stack/templates/libvirt-keysize.yaml parameter_defaults: LibvirtCertificateKeySize: 4096 EOF
cat > /home/stack/templates/libvirt-keysize.yaml parameter_defaults: LibvirtCertificateKeySize: 4096 EOF
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
libvirt-keysize.yaml
配置文件添加到部署脚本中:openstack overcloud deploy --templates \ ... -e /home/stack/templates/libvirt-keysize.yaml ...
openstack overcloud deploy --templates \ ... -e /home/stack/templates/libvirt-keysize.yaml ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 重新运行部署脚本:
./deploy.sh
./deploy.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.8. 固件更新 复制链接链接已复制到粘贴板!
物理服务器使用复杂的固件来启用和运行服务器硬件以及可轻便的管理卡,这些卡可能具有自己的安全漏洞,从而有可能进行系统访问和中断。为解决这些问题,硬件供应商将发布与操作系统更新分开安装的固件更新。您需要一个可操作的安全流程,用于按常规计划检索、测试并实施这些更新,请注意,固件更新通常需要重启物理主机才能生效。
13.9. 使用 SSH 横幅文本 复制链接链接已复制到粘贴板!
您可以设置横幅,向通过 SSH 连接的所有用户显示一个控制台信息。您可以使用环境文件中的以下参数将横幅文本添加到 /etc/issue
中:考虑自定义此示例文本以满足您的要求。
要将此更改应用到您的部署,请将设置保存为名为 ssh_banner.yaml
的文件,然后将其传递到 overcloud deploy
命令,如下所示:& lt;full environment
> 表示您必须仍然包含所有原始部署参数。例如:
openstack overcloud deploy --templates \ -e <full environment> -e ssh_banner.yaml
openstack overcloud deploy --templates \
-e <full environment> -e ssh_banner.yaml
13.10. 系统事件的审计 复制链接链接已复制到粘贴板!
维护所有审计事件的记录可帮助您建立系统基准、执行故障排除或分析导致特定结果的事件序列。审计系统可以记录许多类型的事件,如更改系统时间、Mandatory/Discretionary Access Control 以及创建/删除用户或组。
可以使用环境文件创建规则,然后由 director 注入到 /etc/audit/audit.rules
中。例如:
13.11. 管理防火墙规则 复制链接链接已复制到粘贴板!
防火墙规则在部署过程中自动应用到 overcloud 节点上,旨在仅公开获取 OpenStack 工作所需的端口。您可以根据需要指定额外的防火墙规则。例如,要为 Zabbix 监控系统添加规则:
如果没有设置 action
参数,则结果将 接受
。您只能将 action
参数设置为 drop
,insert
, 或 append
。
您还可以添加限制访问的规则。在规则定义中使用的数字将决定规则的优先级。例如,Rabx 的规则号默认为 109
。如果要静止它,您可以将其切换为使用较低值:
在本例中,098
和 099
是任意选择的数字,它们小于 RabbitMQ 的规则编号 109
。要确定规则的数量,您可以检查适当的节点上的 iptables 规则 ; 对于 RabbitMQ,您需要检查控制器:
iptables-save [...] -A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT
iptables-save
[...]
-A INPUT -p tcp -m multiport --dports 4369,5672,25672 -m comment --comment "109 rabbitmq" -m state --state NEW -j ACCEPT
或者,您还可以从 puppet 定义中提取端口要求。例如,RabbitMQ 的规则存储在 puppet/services/rabbitmq.yaml
中:
可以为规则设置以下参数:
-
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 服务用来创建完整性数据库。例如:
上面的示例没有主动维护或基准测试,因此您应该选择符合您的要求的 AIDE 值。
-
声明了一个名为
TripleORules
的别名,以避免每次都重复使用相同的属性。 -
别名接收
p+sha256
属性。在 AIDE 术语中,这会被解释为:监视所有文件权限p
,带有完整性 checksumsha256
。
有关 AIDE 配置文件可用属性的完整列表,请参见 的 AIDE MAN 页面(https://aide.github.io/)。
完成以下内容以将更改应用到您的部署:
-
将设置保存为
/home/stack/templates/
目录中的名为aide.yaml
的文件。 -
编辑
aide.yaml
环境文件,使其具有适合您环境的参数和值。 在
openstack overcloud deploy
命令中包含/home/stack/templates/aide.yaml
环境文件,以及特定于您环境的所有其他必要的 heat 模板和环境文件:openstack overcloud deploy --templates ... -e /home/stack/templates/aide.yaml
openstack overcloud deploy --templates ... -e /home/stack/templates/aide.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.12.1. 使用复杂 AIDE 规则 复制链接链接已复制到粘贴板!
可使用前面描述的格式创建复杂的规则。例如:
MyAlias = p+i+n+u+g+s+b+m+c+sha512
MyAlias = p+i+n+u+g+s+b+m+c+sha512
以上命令将转换为以下指令:监控权限、索引节点、链接数、用户、组、大小、块数、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
文件中的条目管理。例如:
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
parameter_defaults:
KeystoneNotificationFormat: cadf
13.15. 查看 login.defs 值 复制链接链接已复制到粘贴板!
要强制对新系统用户(非keystone)的密码要求,director 可以通过以下示例参数将条目添加到 /etc/login.defs
中:
第 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 请求都会被拒绝,并引发错误。
流程
在模板中的
parameter_defaults
下,设置HorizonAllowedHosts
参数的值:parameter_defaults: HorizonAllowedHosts: <value>
parameter_defaults: HorizonAllowedHosts: <value>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 将
<value>
替换为 OpenStack 仪表板提供的 FQDN。- 使用修改后的模板以及您的环境所需的所有其他模板,部署 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
parameter_defaults:
ControllerExtraConfig:
horizon::disallow_iframe_embed: false
只有在完全理解潜在的安全影响后,这些设置才应设置为 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
horizon::enable_secure_proxy_ssl_header: true
验证
部署 overcloud 后,检查 Red Hat OpenStack Dashboard (horizon)的 local_settings
文件进行验证。
使用
ssh
连接到控制器:ssh tripleo-admin@controller-0
$ ssh tripleo-admin@controller-0
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 检查
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')
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 Copied! Toggle word wrap Toggle overflow
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'
horizon::cache_backend: django.core.cache.backends.memcached.MemcachedCache
horizon::django_session_engine: 'django.contrib.sessions.backends.cache'
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)可以使用密码验证检查来强制实施密码复杂性。
流程
- 指定用于密码验证的正则表达式,以及用于失败测试的帮助文本。以下示例要求用户创建长度为 8 到 18 个字符之间的密码:
parameter_defaults: HorizonPasswordValidator: '^.{8,18}$' HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'
parameter_defaults:
HorizonPasswordValidator: '^.{8,18}$'
HorizonPasswordValidatorHelp: 'Password must be between 8 and 18 characters.'
-
将此更改应用到您的部署。将设置保存为名为
horizon_password.yaml
的文件,然后将其传递给overcloud 部署命令
,如下所示:<full environment
> 表示您必须仍然包含所有原始部署参数。例如:
openstack overcloud deploy --templates \ -e <full environment> -e horizon_password.yaml
openstack overcloud deploy --templates \
-e <full environment> -e horizon_password.yaml
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
parameter_defaults:
ControllerExtraConfig:
horizon::enforce_password_check: false
14.16. 禁用显示的密码 复制链接链接已复制到粘贴板!
disable_password_reveal
参数默认设置为 True
,但如果需要,可以使用环境文件来禁用它。密码图示按钮允许用户在仪表板中查看他们要输入的密码。
流程
-
在
ControllerExtraConfig
参数下,包含horizon::disable_password_reveal: false
。将它保存到 heat 环境文件中,并将它包含在您的部署命令中。
Example
parameter_defaults: ControllerExtraConfig: horizon::disable_password_reveal: false
parameter_defaults:
ControllerExtraConfig:
horizon::disable_password_reveal: false
只有在完全理解潜在的安全影响后,这些设置才应设置为 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 横幅:
流程
只在
{% 包括 'auth/_login.html' %}
部分前输入所需的 logon 横幅。允许 HTML 标签:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上例生成类似如下的仪表板:
其他资源
14.18. 限制文件上传的大小 复制链接链接已复制到粘贴板!
您可以选择将仪表板配置为限制文件上传的大小;此设置可能是各种安全强化策略的要求。
LimitRequestBody
- 此值(以字节为单位)限制您可以使用控制面板(如镜像和其他大型文件)传输的文件的最大大小。
此设置尚未由红帽正式测试。建议您在将此设置部署到生产环境中前全面测试此设置的影响。
如果值太小,文件上传将失败。
例如,此设置将每个文件上传到最大大小 10 GB (10737418240
)。您需要调整这个值以适合您的部署。
/var/lib/config-data/puppet-generated/horizon/etc/httpd/conf/httpd.conf
<Directory /> LimitRequestBody 10737418240 </Directory>
<Directory /> LimitRequestBody 10737418240 </Directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/10-horizon_vhost.conf
<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /var/lib/config-data/puppet-generated/horizon/etc/httpd/conf.d/15-horizon_ssl_vhost.conf
<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
<Directory "/var/www"> LimitRequestBody 10737418240 </Directory>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
这些配置文件由 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_host
和 bind_port
:
Address to bind the API server Port the bind the API server to
# Address to bind the API server
bind_host = IP ADDRESS OF SERVER
# Port the bind the API server to
bind_port = 9696
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 端点:
第 16 章 在 Red Hat OpenStack Platform 中强化块存储 复制链接链接已复制到粘贴板!
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
参数可以接受 zero
或 shred
作为参数。零
会将一次零传递写入设备。shred
操作将编写三个预先确定的位模式。
第 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-server
、container-server
、account-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 {} \;
chown -R root:swift /var/lib/config-data/puppet-generated/swift/etc/swift/*
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type f -exec chmod 640 {} \;
find /var/lib/config-data/puppet-generated/swift/etc/swift/ -type d -exec chmod 750 {} \;
此限制仅允许 root 修改配置文件,同时仍然允许服务读取这些文件,因为其在 swift
组中的成员资格。
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.
The sanitization process removes information from the media such that the information cannot be retrieved or reconstructed. Sanitization techniques, including clearing, purging, cryptographic erase, and destruction, prevent the disclosure of information to unauthorized individuals when such media is reused or released for disposal.
在开发常规数据处理和清理指南时,云操作员应考虑以下事项(根据 NIST 推荐的安全控制):
- 跟踪、记录和验证介质清理和处理操作。
- 测试清理设备和流程以验证适当的性能。
- 在将此类设备连接到云基础架构之前,清理可移植的可移动存储设备。
- 销毁无法清理的云系统介质。
因此,OpenStack 部署需要解决以下做法(例如,其他部署):
- 保护数据纠删代码
- 实例内存清理
- 块存储卷数据
- 计算实例临时存储
- 裸机服务器清理
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-
前缀的标头的PUT
或POST
请求发送元数据。
以上列表中未包含的任何数据或元数据都不会被加密,包括:
- 帐户、容器和对象名称
- 帐户和容器自定义用户元数据值
- 所有自定义用户元数据名称
- 对象 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。
流程
在 heat 模板中,通过将
True
的值设置为VerifyGlanceSignatures
参数来启用实例签名验证:parameter_defaults: VerifyGlanceSignatures: True
parameter_defaults: VerifyGlanceSignatures: True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
确保
openstack overcloud deploy
脚本中包含用于修改VerifyGlanceSignatures
参数的模板,并重新运行 deploy 脚本。
如果您使用未签名的镜像创建实例,则镜像会失败验证,实例也不会启动。有关对镜像进行签名的更多信息,请参阅 签署镜像服务镜像。
21.6. 迁移实例 复制链接链接已复制到粘贴板!
OpenStack 和底层虚拟化层为 OpenStack 节点之间的镜像实时迁移提供,允许您在不造成实例停机时间的情况下无缝地执行 Compute 节点的滚动升级。但是,实时迁移也会带来重大风险。要了解涉及的风险,以下是在实时迁移过程中执行的高级别步骤:
- 在目标主机上启动实例
- 转让内存
- 停止客户机和同步磁盘
- 传输状态
- 启动客户机
某些操作(如冷迁移、调整大小和 shelve)可能会导致在网络上将实例的数据传送到其他服务等。
21.6.1. 实时迁移风险 复制链接链接已复制到粘贴板!
在实时迁移过程的不同阶段,实例运行时间内存和磁盘的内容以纯文本通过网络传输。因此,在使用实时迁移时需要解决多个风险。以下非应对列表详细介绍了其中的一些风险:
- 拒绝服务(DoS):在迁移过程中出现问题,则实例可能会丢失。
- 数据暴露:必须安全处理内存或磁盘传输。
- 数据操作:如果没有安全处理内存或磁盘传输,攻击者可以在迁移过程中操作用户数据。
- 代码注入:如果没有安全处理内存或磁盘传输,攻击者可以在迁移过程中对可执行文件进行操作。
21.6.2. 禁用实时迁移 复制链接链接已复制到粘贴板!
目前,OpenStack 中默认启用实时迁移。默认情况下,实时迁移是仅管理员的任务,因此用户无法启动此操作,而只有管理员(可能被信任)。可以通过在 nova policy.json
文件中添加以下行来禁用实时迁移:
"compute_extension:admin_actions:migrate": "!", "compute_extension:admin_actions:migrateLive": "!",
"compute_extension:admin_actions:migrate": "!",
"compute_extension:admin_actions:migrateLive": "!",
或者,当阻止 TCP 端口 49152
到 49261
时,实时迁移可能会失败,或者确保 nova 用户在计算主机之间没有免密码 SSH 访问。
请注意,实时迁移的 SSH 配置可显著锁定:创建新用户(nova_migration),并且 SSH 密钥仅限于该用户,并且仅在允许的网络上使用。然后,打包程序脚本会限制可运行的命令(例如,libvirt 套接字上的 netcat)。
21.6.3. 加密实时迁移 复制链接链接已复制到粘贴板!
实时迁移流量以纯文本格式传输正在运行的实例的磁盘和内存内容,目前默认托管在内部 API 网络上。
如果有足够的要求(如升级)来保持实时迁移,则 libvirtd 可以为实时迁移提供加密的隧道。但是,此功能不会在 OpenStack Dashboard 或 nova-client 命令中公开,只能通过手动配置 libvirtd 来访问。然后,实时迁移过程会更改为以下高级别步骤:
- 实例数据从 hypervisor 复制到 libvirtd。
- 在源和目标主机上的 libvirtd 进程间创建一个加密的隧道。
- 目标 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
使用6080
和13080
。 -
确认 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
:
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 配置:
将 RABBIT_PASS
替换为合适的密码。
22.4. Qpid 的 OpenStack 服务配置 复制链接链接已复制到粘贴板!
本节介绍 OpenStack 服务的典型 Qpid 配置:
使用合适的密码替换 QPID_PASS
。
另外,如果将 SASL 与 Qpid 搭配使用,则可通过添加来指定正在使用的 SASL 机制:
qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>
qpid_sasl_mechanisms = <space separated list of SASL mechanisms to use for auth>
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 访问。
流程
作为云管理员,创建单独的 heat 模板环境文件,如
lock-down-glance-metadef-api.yaml
,使其包含镜像服务 metadef API 的策略覆盖:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 在部署 overcloud 时,在部署命令中包含策略覆盖的环境文件,使用
-e
选项:openstack overcloud deploy -e lock-down-glance-metadef-api.yaml
$ openstack overcloud deploy -e lock-down-glance-metadef-api.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.5.2. 启用 metadef API 复制链接链接已复制到粘贴板!
如果您之前限制的元数据定义(metadef) API 或想要重新放置新默认值,您可以覆盖 metadef 修改策略,以允许用户更新其相应资源。
具有依赖于写入 metadef API 访问权限的用户的云管理员可以使所有用户都可以访问这些 API。但是,在这种配置中,可能会意外泄漏敏感资源名称,如客户名称和内部项目。管理员必须审核其系统,以识别之前创建的资源可能存在安全漏洞,即使所有用户只启用了读取访问权限。
流程
作为云管理员,登录 undercloud 并为策略覆盖创建一个文件。例如:
cat open-up-glance-api-metadef.yaml
$ cat open-up-glance-api-metadef.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 配置策略覆盖文件,以允许 metadef API 对所有用户进行读写访问:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注意您必须将所有 metadef 策略配置为使用
rule:metadeta_default
。在部署 overcloud 时,将新策略文件包含在部署命令中,并使用
-e
选项:openstack overcloud deploy -e open-up-glance-api-metadef.yaml
$ openstack overcloud deploy -e open-up-glance-api-metadef.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
23.6. 更改 HAProxy 的 SSL/TLS 密码和规则 复制链接链接已复制到粘贴板!
如果在 overcloud 中启用了 SSL/TLS,请考虑强化与 HAProxy 配置一起使用的 SSL/TLS 密码和规则。通过强化 SSL/TLS 密码,您可以避免 SSL/TLS 漏洞,如 POODLE 漏洞。
创建名为
tls-ciphers.yaml
的 heat 模板环境文件:touch ~/templates/tls-ciphers.yaml
touch ~/templates/tls-ciphers.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 使用环境文件中的
ExtraConfig
hook 将值应用到tripleo::haproxy::ssl_cipher_suite
和tripleo::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
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 Copied! Toggle word wrap Toggle overflow 注意cipher 集合是一个连续行。
在部署 overcloud 时,使用 overcloud deploy 命令包含
tls-ciphers.yaml
环境文件:openstack overcloud deploy --templates \ ... -e /home/stack/templates/tls-ciphers.yaml ...
openstack overcloud deploy --templates \ ... -e /home/stack/templates/tls-ciphers.yaml ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
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 可以接收这些断言。