检查清单¶
检查块-01：配置文件用户/组所有权是否设置为 root/cinder?¶
配置文件包含组件平稳运行所需的关键参数和信息。如果未授权用户（无论是故意还是意外）修改或删除任何参数或文件本身，都将导致严重的可访问性问题，从而导致其他端用户服务中断。因此，此类关键配置文件的用户所有权必须设置为 root，组所有权必须设置为 cinder。此外，包含目录应具有相同的所有权，以确保正确拥有新文件。
运行以下命令
$ stat -L -c "%U %G" /etc/cinder/cinder.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/api-paste.ini | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/policy.json | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder/rootwrap.conf | egrep "root cinder"
$ stat -L -c "%U %G" /etc/cinder | egrep "root cinder"
通过：如果所有这些配置文件的用户和组所有权分别设置为 root 和 cinder。上述命令显示 root cinder 的输出。
失败：如果上述命令未返回任何输出，因为用户和组所有权可能已设置为 root 或 cinder 以外的任何用户或组。
检查块-02：是否为配置文件设置了严格的权限?¶
与之前的检查类似，我们建议为这些配置文件设置严格的访问权限。
运行以下命令
$ stat -L -c "%a" /etc/cinder/cinder.conf
$ stat -L -c "%a" /etc/cinder/api-paste.ini
$ stat -L -c "%a" /etc/cinder/policy.json
$ stat -L -c "%a" /etc/cinder/rootwrap.conf
$ stat -L -c "%a" /etc/cinder
也可以进行更广泛的限制：如果包含目录设置为 750，则可以保证在此目录中创建的新文件将具有所需的权限。
通过：如果权限设置为 640 或更严格，或者包含目录设置为 750。权限 640/750 转换为所有者 r/w，组 r，且无其他权限，即“u=rw,g=r,o=”。请注意，使用 检查块-01：配置文件用户/组所有权是否设置为 root/cinder? 和权限设置为 640，root 具有读/写访问权限，cinder 具有对这些配置文件的读取访问权限。可以使用以下命令验证访问权限。如果您的系统支持 ACL，则此命令才可用。
$ getfacl --tabular -a /etc/cinder/cinder.conf
getfacl: Removing leading '/' from absolute path names
# file: etc/cinder/cinder.conf
USER root rw-
GROUP cinder r--
mask r--
other ---
失败： 如果权限未设置为至少 640。
检查块-03：是否使用 keystone 进行身份验证?¶
注意
此项目仅适用于 Rocky 及更早的 OpenStack 版本，因为 auth_strategy 在 Stein 中已被弃用。
OpenStack 支持各种身份验证策略，例如 noauth、keystone 等。如果使用“noauth”策略，则用户可以在没有身份验证的情况下与 OpenStack 服务交互。这可能是一种潜在的风险，因为攻击者可能会获得对 OpenStack 组件的未经授权访问。因此，我们强烈建议所有服务都使用其服务帐户通过 keystone 进行身份验证。
通过：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 auth_strategy 的值设置为 keystone。
失败：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 auth_strategy 的值设置为 noauth。
检查块-04：是否为身份验证启用了 TLS?¶
OpenStack 组件使用各种协议相互通信，并且通信可能涉及敏感/机密数据。攻击者可能会尝试窃听通道以获取对敏感信息的访问权限。因此，所有组件必须使用安全的通信协议相互通信。
通过：如果 /etc/cinder/cinder.conf 中 [keystone_authtoken] 部分下参数 www_authenticate_uri 的值设置为以 https:// 开头的 Identity API 端点，并且 /etc/cinder/cinder.conf 中相同 [keystone_authtoken] 部分下的参数 insecure 的值设置为 False。
失败：如果 /etc/cinder/cinder.conf 中 [keystone_authtoken] 部分下参数 www_authenticate_uri 的值未设置为以 https:// 开头的 Identity API 端点，或者 /etc/cinder/cinder.conf 中相同 [keystone_authtoken] 部分下的参数 insecure 的值设置为 True。
检查块-05：cinder 是否通过 TLS 与 nova 通信?¶
OpenStack 组件使用各种协议相互通信，并且通信可能涉及敏感/机密数据。攻击者可能会尝试窃听通道以获取对敏感信息的访问权限。因此，所有组件必须使用安全的通信协议相互通信。
通过：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nova_api_insecure 的值设置为 False。
失败：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nova_api_insecure 的值设置为 True。
检查块-06：cinder 是否通过 TLS 与 glance 通信?¶
与之前的检查 (检查块-05：cinder 是否通过 TLS 与 nova 通信?) 类似，我们建议所有组件使用安全的通信协议相互通信。
通过：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 glance_api_insecure 的值设置为 False，并且参数 glance_api_servers 的值设置为以 https:// 开头的值。
失败：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 glance_api_insecure 的值设置为 True，或者参数 glance_api_servers 的值设置为不以 https:// 开头的值。
检查块-07：NAS 是否在安全的环境中运行?¶
Cinder 支持 NFS 驱动程序，其工作方式与传统的块存储驱动程序不同。NFS 驱动程序实际上不允许实例在块级别访问存储设备。相反，文件是在 NFS 共享上创建的，并映射到实例，从而模拟了块设备。Cinder 可以通过控制 cinder 卷创建时文件权限来安全地配置这些文件。Cinder 配置还可以控制文件操作是作为 root 用户还是当前 OpenStack 进程用户运行。
通过：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nas_secure_file_permissions 的值设置为 auto。设置为 auto 时，将在 cinder 启动期间检查是否存在现有的 cinder 卷，如果没有卷将选项设置为 True，并使用安全的文件权限。检测到现有卷将选项设置为 False，并使用当前处理文件权限的不安全方法。对于新安装，将写入“标记文件”，以便 cinder 的后续重启将知道最初的确定是什么。如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nas_secure_file_operations 的值设置为 auto。设置为“auto”时，将在 cinder 启动期间检查是否存在现有的 cinder 卷，如果没有卷将选项设置为 True，安全且不作为 root 用户运行。检测到现有卷将选项设置为 False，并使用当前以 root 用户运行操作的方法。
失败：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nas_secure_file_permissions 的值设置为 False，并且如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 nas_secure_file_operations 的值设置为 False。
检查块-08：请求体的最大大小是否设置为默认值 (114688)?¶
如果未定义每个请求的最大主体大小，攻击者可以创建任意大小的 osapi 请求，导致服务崩溃并最终导致拒绝服务攻击。分配最大值可确保阻止任何恶意的大型请求，从而确保服务的持续可用性。
通过：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 osapi_max_request_body_size 的值设置为 114688，或者如果 /etc/cinder/cinder.conf 中 [oslo_middleware] 部分下参数 max_request_body_size 的值设置为 114688。
失败：如果 /etc/cinder/cinder.conf 中 [DEFAULT] 部分下参数 osapi_max_request_body_size 的值未设置为 114688，或者如果 /etc/cinder/cinder.conf 中 [oslo_middleware] 部分下参数 max_request_body_size 的值未设置为 114688。
检查块-09：是否启用了卷加密功能?¶
未加密的卷数据使卷托管平台成为攻击者的特别有价值的目标，因为它允许攻击者读取许多不同 VM 的数据。此外，物理存储介质可能会被盗、重新挂载并从另一台机器访问。加密卷数据可以减轻这些风险，并为卷托管平台提供纵深防御。块存储 (cinder) 能够在将卷数据写入磁盘之前对其进行加密，我们建议启用卷加密功能。请参阅 Openstack Cinder 服务配置文档的 卷加密 部分，了解说明。
通过：如果 1) /etc/cinder/cinder.conf 中 [key_manager] 部分下参数 backend 的值已设置，2) /etc/nova/nova.conf 中 [key_manager] 下参数 backend 的值已设置，并且 3) 如果正确遵循了上述文档中的说明。
为了进一步验证，请在完成卷加密设置并创建 LUKS 卷类型后（如上述参考文档中所述），执行以下步骤。
创建 VM
$ openstack server create --image cirros-0.3.1-x86_64-disk --flavor m1.tiny TESTVM
创建加密卷并将其附加到您的 VM
$ openstack volume create --size 1 --type LUKS 'encrypted volume' $ openstack volume list $ openstack server add volume --device /dev/vdb TESTVM 'encrypted volume'
在 VM 上，将一些文本发送到新附加的卷并同步它
# echo "Hello, world (encrypted /dev/vdb)" >> /dev/vdb # sync && sleep 2
在托管 cinder 卷服务的系统上，同步以刷新 I/O 缓存，然后测试是否可以找到写入加密卷的字符串
# sync && sleep 2 # strings /dev/stack-volumes/volume-* | grep "Hello"
搜索不应返回写入加密卷的字符串。
失败：如果 /etc/cinder/cinder.conf 中 [key_manager] 部分下参数 backend 的值未设置，或者如果 /etc/nova/nova.conf 中 [key_manager] 部分下参数 backend 的值未设置，或者如果未正确遵循上述文档中的说明。
