策略应尽可能在 API REST 层强制执行¶
https://blueprints.launchpad.net/nova/+spec/v3-api-policy
此 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 层)以不同的名称进行重复检查。 此外,在 db 层中也存在一些硬编码的权限检查。
这种情况使得操作员更难正确配置他们想要的策略设置,并且由于多层级的复杂性,实现本身更容易受到安全漏洞的影响。
问题详细描述
权限检查分散在 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”: “”
DB 层硬编码策略检查 示例
@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. 操作员希望指定的角色可以访问 service 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
移除 db 层的硬编码权限检查
对于 v2.1 API,我们移除 DB 层的所有硬编码权限检查。 并且我们应该确保在 REST API 层有策略检查。
对于 v2 API,我们移除 DB 层的所有硬编码权限检查,并将硬编码权限检查移动到 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 版本。 因为在有了 Micro-version 之后,版本会经常变化。
对于与 volume 相关的扩展,没有什么可以做的,REST API 层已经有策略检查,cinder 也有策略检查。
对于与 network 相关的扩展,我们正在进行与 compute API 相同的更改。
对于 nova-network,将所有策略强制执行从 network API 移动到 REST API 层,并移除 db 层的硬编码权限检查。
对于 neutron,我们没有什么可以做的,neutron 有自己的策略强制执行。 我们只需要确保在 nova REST API 层有策略强制执行。
备选方案¶
替代方案是维持现状,这对于部署者和开发人员来说都令人困惑,因为他们需要维护当前的实现。
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
此 BP 将移除 compute API 层和 DB 层的策略权限检查。
这些补丁需要非常严格的双重检查和高质量的审查,以确保不会引入安全漏洞,因为 nova 内部调用可以从许多不同的代码路径(Ec2、V2 API、V2.1 API 和其他内部路径)调用。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
此 BP 将提高错误处理性能。 由于权限检查发生在 API 层而不是 Nova 的较低层级,因此在请求被拒绝之前,将发生更少的处理。 此外,对于较新版本的 API,冗余的策略检查也被移除,这也将提高性能。
其他部署者影响¶
将尽一切努力保持 v2 API 的所有现有策略权限设置向后兼容,除了 db 硬编码的权限检查。 因为 v2 API 将在 v2.1 API 准备就绪后移除。
由于 v2.1 API 尚未准备就绪,目前还没有 v2.1 的用户,因此我们不必担心任何更改会影响用户。
对于 EC2 API,我们也希望保持向后兼容性,就像 v2 API 一样。 旧策略规则至少会保留一个版本。 如果用户只想使用旧策略,用户可以将所有新策略设置为空。 然后所有策略将被跳过。 如果用户想使用新策略,只需将规则设置为新策略,然后将强制执行新策略,然后再执行旧策略。
移除 db 层硬编码权限检查会影响以下扩展
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 时,策略权限检查将仅在 REST API 层添加。
实现¶
负责人¶
- 主要负责人
Alex Xu <hejie.xu@intel.com>
- 其他贡献者
Ji Chen <jichenjc@cn.ibm.com> Shuangtai Tian <shuangtai.tian@intel.com> Chris Yeoh <cyeoh@au1.ibm.com>
工作项¶
为 compute 和 network API 添加跳过策略检查的参数。
改进 EC2 API 策略强制执行
在 REST API 层添加新的策略规则
添加新的 EC2 API 规则
将 EC2 API 规则移动到单独的文件中。
改进 V2.1 API 策略强制执行
移除 compute API 和 network API 层的策略强制执行
重命名 V2.1 API 规则
将 V2.1 API 规则移动到单独的文件中。
移除 db 层硬编码权限检查。
为 v2 API 在 REST API 层添加向后兼容规则
在 v2.1 API 处添加策略规则,而不是硬编码检查
将 V2 API 策略移出 policy.conf
依赖项¶
无
测试¶
没有 tempest 更改。 所有策略检查测试将由 unittest 测试,因为这主要是 Nova 的内部蓝图。
文档影响¶
DB 层的权限检查将被删除,这应该在升级文档中记录。
所有策略都应在 API 层强制执行,这应该在开发人员文档中记录。
对于策略规则的一致配置,这应该在 Cloud Admin 文档中记录。
参考资料¶
https://etherpad.openstack.org/p/icehouse-summit-nova-v3-api