策略应尽可能在 API REST 层强制执行（最终部分)¶

https://blueprints.launchpad.net/nova/+spec/nova-api-policy-final-part

注意：此规格是 nova api 策略蓝图的后续工作：https://blueprints.launchpad.net/nova/+spec/v3-api-policy ，在 Kilo 中，v2.1 策略改进已经完成，但仅完成了部分数据库策略改进，其余工作将在 Liberty 中继续。详情请参见“工作项目”部分。

此 BP 建议仅在 Nova REST API 层强制执行所有策略检查。Nova 较低层级的额外权限检查将被移除。V2.1 API 将具有一致的策略命名，并保留与 V2 API 相关的现有策略检查的向后兼容性，以便即使策略检查在实践中可能在不同的点实现，策略检查在效果上仍然相同。

此 BP 已经在 Icehouse 会议上讨论过：https://etherpad.openstack.org/p/icehouse-summit-nova-v3-api

问题描述¶

目前，策略权限检查分散在 Nova 代码的各个层级。在不同的层级（例如 Nova REST API 层和 Nova Compute API 层）执行实际上是相同类型的策略检查，也存在重复检查的情况。此外，在数据库层中也存在一些硬编码的权限检查。

这种情况使得操作员更难以正确配置他们想要的策略设置，并且由于多层级的复杂性，实现本身更容易受到安全漏洞的影响。

问题详细描述

权限检查分散在 nova 代码的不同层级示例
- REST API 层：暂停服务器 “compute_extension:admin_actions:pause”
- Compute API 层：在 compute API 中暂停 “compute:pause”
- DB 层：为 db API service_get 使用 require_admin_context 装饰器
针对相同 API 的重复策略检查示例
- 对于服务器的暂停操作
- REST API 层
  “compute_extension:admin_actions:pause”: “rule:admin_or_owner”
- Compute API 层: “compute:pause”: “”
数据库层硬编码策略检查示例

  @require_admin_context
  def service_get_all(context, disabled=None):
      query = model_query(context, models.Service)

      if disabled is not None:
          query = query.filter_by(disabled=disabled)

      return query.all()

This means it won't have any effect after you modify the policy at REST
API layer, it always enforced as admin at db layer.

用例¶

1. 操作员希望指定的角色可以访问服务 API，但它被硬编码为只有管理员才能操作这些 API。

2. 从开发人员的角度来看，暂停服务器 API 在 REST API 层只有一个规则。开发人员不必对如何在 nova 中处理权限检查感到困惑。

项目优先级¶

无

提议的变更¶

在 REST API 层强制执行策略。因为 REST API 将访问不同的内部 API，例如 compute API、DB API 或其他内部 API，所以 REST API 层是统一强制执行策略的地方。

移除 EC2 和 Nova V2.1 API 的 compute API 层策略检查
- 对于 V2.1 API，只有 nova REST API 层才会进行策略检查。compute API 将有一个参数 ‘skip_policy_check’ 来控制是否执行策略检查。对于 V2.1 API，skip_policy_check 将为 True。
  
  https://review.openstack.org/#/c/100408/2/nova/api/openstack/compute/plugins/v3/shelve.py
- 对于 Ec2，我们希望保持向后兼容性。我们还希望将 compute API 层的策略检查移动到 REST API 层，就像 V2.1 API 一样。这意味着旧策略和新策略将同时可用。至少在发布一个版本后，我们可以移除旧策略。
- 对于 V2 API，我们希望保持向后兼容性。因此，我们不会将 compute API 层的策略检查移动到 REST API 层。我们将 compute API 的参数 skip_policy_check 设置为 False，这意味着仍然在 compute API 层执行策略检查。这是因为 V2 API 将被弃用。在移除 V2 API 之前，我们不必冒破坏现有代码的风险。
  
  https://review.openstack.org/#/c/100408/2/nova/compute/api.py
移除数据库层硬编码的权限检查
- 示例：https://review.openstack.org/#/c/73490/
- 对于 v2.1 API，我们移除数据库层的所有硬编码权限检查。我们应该确保在 REST API 层有策略检查。
- 对于 v2 API，我们移除数据库层的所有硬编码权限检查，并将硬编码的权限检查移动到 REST API 层以保持向后兼容性。V2 API 将在 V2.1 准备就绪后移除，这可以降低破坏现有内容的风险。
- 更新策略配置文件以匹配 EC2 和 V2.1 API 的现有行为。
更正 v2.1 api 和 ec2 api 的策略规则名称规范

策略命名风格如下
对于 V2.1：api:[extension_alias]:[action] 对于 ec2：ec2_api:[action]
- 我们不会使用 ‘compute’ 和 ‘compute_extension’ 来区分核心和扩展 API。因为核心 API 可能会在未来发生变化。
- 我们还从策略规则中移除 API 版本。因为在有了微版本之后，版本会经常变化。
对于与 volume 相关的扩展，没有什么可以做的，REST API 层已经有策略检查，cinder 也有策略检查。
对于与网络相关的扩展，我们正在进行与 compute API 相同的更改。

对于 nova-network，将所有策略强制执行从网络 API 移动到 REST API 层，并移除数据库层的硬编码权限检查。

对于 neutron，我们没有什么可以做的，neutron 有自己的策略强制执行。我们只需要确保在 nova REST API 层有策略强制执行。

备选方案¶

另一种选择是维持现状，这对于部署者和开发人员来说都令人困惑，因为他们需要维护当前的实现。

数据模型影响¶

无

REST API 影响¶

无

安全影响¶

此 BP 将移除 compute API 层和 DB 层的策略权限检查。

这些补丁需要非常严格的双重检查和高质量的审查，以确保不会引入安全漏洞，因为 nova 内部调用可以从许多不同的代码路径（Ec2、V2 API、V2.1 API 和其他内部路径）调用。

通知影响¶

无

其他最终用户影响¶

无

性能影响¶

此 BP 将提高错误处理性能。因为权限检查发生在 API 层而不是 Nova 的较低层级，所以请求被拒绝之前会发生更少的处理。此外，对于较新版本的 API，冗余的策略检查也被移除，这也将提高性能。

其他部署者影响¶

将尽一切努力保持所有现有的策略权限设置与 v2 API 向后兼容，除了数据库硬编码的权限检查。因为 v2 API 将在 v2.1 API 准备就绪后移除。

由于 v2.1 API 尚未准备就绪，目前还没有 v2.1 的用户，所以我们不必担心任何更改会影响用户。

对于 EC2 API，我们也希望保持向后兼容性，就像 v2 API 一样。旧策略规则至少会保留一个版本。如果用户只想使用旧策略，用户可以将所有新策略设置为空。然后所有策略将被跳过。如果用户想使用新策略，只需将规则设置为新策略，然后新策略将在旧策略之前强制执行。

扩展将受到移除数据库层硬编码权限检查的影响，如下所示

services
certificates
floating_ips
floating_ips_bulk
floating_ip_dns
fixed_ips
os-network
network_associate
quotas
quota_classes
security_group
security_group_default_rule
migrations
flavor_manage
flavor_access
cell
agent
pci

对于 v2.1 和 ec2 api，策略规则名称前缀已更改。因此，部署者需要更新他们的策略配置。

开发人员影响¶

当开发人员添加新的 REST API 时，nova 策略权限检查将仅在 REST API 层添加。

实现¶

负责人¶

主要负责人: Alex Xu <hejie.xu@intel.com>
其他贡献者: Eli Qiao <liyong.qiao@intel.com> ShaoHe Feng <shaohe.feng@intel.com> YunTong Jin <yuntong.jin@intel.com> Park Hei <heijlong@linux.vnet.ibm.com> jichenjc <jichenjc@cn.ibm.com>

工作项¶

带有“(完成)”的任务表示已经在 Kilo 中完成。其他任务将继续进行。

添加参数到 compute 和 network API 以跳过策略检查。（完成）
改进 EC2 API 策略强制执行。（放弃，因为 EC2 已弃用）
- 在 REST API 层添加新的策略规则
- 添加新的 EC2 API 规则
- 将 EC2 API 规则移动到单独的文件。
改进 V2.1 API 策略强制执行。（完成）
- 移除 compute API 和 network API 层的策略强制执行
- 重命名 V2.1 API 规则
- 将 V2.1 API 规则移动到单独的文件。
移除数据库层硬编码的权限检查。大部分与 nova-network 和 service/compute_nodes 数据库调用有关。
- 为 v2 API 在 REST API 层添加回滚兼容性规则
- 在 REST API 层添加策略规则，而不是 v2.1 的硬编码检查
将 V2 API 策略从 policy.conf 中移除

工作列表：https://etherpad.openstack.org/p/apipolicycheck

依赖项¶

无

测试¶

没有 tempest 更改。所有策略检查测试将由 unittest 测试，因为这主要是 nova 的内部蓝图。

文档影响¶

数据库层的权限检查将被删除，这应该在升级文档中记录。

所有策略都应在 API 层强制执行，这应该在开发人员文档中记录。

对于策略规则的一致配置，这应该在云管理员文档中记录。

参考资料¶

https://etherpad.openstack.org/p/icehouse-summit-nova-v3-api

在 API REST 层尽可能地强制执行策略 (最终部分)