secure-rbac - X-Project-Id 传递¶

bug #1925684

正如 Wallaby PTG [1] 中讨论的那样，为系统范围凭证实施 secure-rbac 策略对于某些 API 需要项目 ID 的项目来说可能具有挑战性。

本规范建议修改 Keystone 中间件，以便为这种 API 提供一个项目 ID 以在上下文中使用的。这应该使项目能够在大多数情况下编写和使用系统范围策略规则，而无需更改代码。

从最终用户角度来看，这将允许操作员轻松管理任何项目拥有的资源。

问题描述¶

由 Keystone 发出的系统范围令牌不包含项目 ID。这对于其 API 实现假定始终可用 UUID 的服务来说是一个问题。

尝试使用系统范围令牌与这些 API 通常会导致错误或意外行为。例如，某些 Barbican API 调用在操作中返回 5XX 内部错误，这些操作假定请求上下文中存在 UUID 格式的项目 ID。

同样，Nova 在使用不提供项目 ID 的令牌发送请求时也返回 500 错误。[2]

提议的变更¶

当前，keystone 中间件在身份验证后通过添加来自身份验证数据的上下文标头来修改请求。对于项目范围令牌，它添加一个 X-Project-Id 标头（从 WSGI 的角度来看与 HTTP_X_PROJECT_ID 相同）。对于系统范围令牌，未添加此标头，这会导致在许多情况下值为 None。

出于安全原因，中间件当前在身份验证之前删除许多标头，包括 X-Project-Id。这是有道理的，因为我们希望防止恶意用户尝试将未经身份验证的上下文数据注入到请求中。

建议的解决方案将更改每次删除 X-Project-Id 的“清理”行为，以允许将其传递给使用系统范围凭证发出的请求

如果存在，则缓存 X-Project-Id 标头
提供凭证已通过身份验证
当提供的凭证是项目范围时，丢弃缓存的值，并使用来自身份验证数据的值
当提供的凭证是系统范围时，将缓存的值添加到请求中的 X-Project-Id 标头。

备选方案¶

讨论了另外两种替代方案

使用明确的角色分配包装项目拥有的资源上的操作。
优点
- 通过 keystone 中的角色分配提供明确的审计跟踪
- 确保对项目拥有的资源的操作必须使用项目范围令牌完成
缺点
- 非常繁琐，并将增加系统用户处理项目拥有的资源所需的时间
- 由于无法获取针对不存在的项目进行作用域的令牌，因此无法用于系统用户清理不存在的项目中的资源。例如，您无法在从 Keystone 中删除项目后清理孤立资源。
- 可能会导致系统用户的剩余角色分配
- 由于它们没有在 keystone 中创建角色分配的能力（这是一个可写操作），因此不适用于系统读取器
使用来自域的继承角色分配。
优点
- 比方法 #1 更简洁，因为它不需要显式分配
- 确保对项目拥有的资源的操作必须使用项目范围令牌完成
缺点
- 必须为每个系统用户在每个域上完成，这些都是动态资源（例如，是否需要流程文档？）
- 如果系统读取器在域上获得管理员或成员角色，则可能存在权限升级的风险（谁对此负责，部署工具？用户？）
- 由于它们没有在 keystone 中创建角色分配的能力（这是一个可写操作），因此不适用于系统读取器

有关其优缺点的详细信息，请参阅 Xena 笔记 [1]。

这两个替代方案与本规范的一个关键区别是，本规范不需要 Keystone 发出客户端使用的项目令牌。

相反，本规范允许对针对系统范围和分配给该用户的系统角色的 RBAC 规则进行强制执行，同时仍然提供项目 ID 以供上下文使用。

安全影响¶

如前所述，删除 X-Project-Id，就像当前中间件所做的那样，是一种很好的做法。我们应该考虑允许系统范围请求传递可能产生的任何不利影响。

能够审计系统范围请求何时使用此传递也很重要。

通知影响¶

无

其他最终用户影响¶

客户端需要更新，以便在使用系统范围令牌时能够在请求中提供项目 ID。例如：

openstack secret list –os-project-id XXXXX-XXXX-XXXX-XXXX

应该在发送之前将该项目 ID 添加到请求标头。

如果请求具有多个项目 ID，KSM 应该失败。原因是，目前只有当删除请求中的所有 X-Project-Id 标头时，才会将一个项目 ID 添加到标头。允许更多可能会导致意想不到的副作用和/或错误。

性能影响¶

此更改不会产生性能影响，因为它仅影响系统范围用户（操作员）。

其他部署者影响¶

无

开发人员影响¶

希望这能够使具有内置上下文项目 ID 假设的 API 能够在不更改任何代码的情况下与系统范围请求一起工作。

实现¶

负责人¶

Douglas Mendizábal (redrobot)
Lance Bragstad (lbragstad)

工作项¶

实施中间件更改
实施客户端更改
实施 keystoneauth 的其他更改，以确保如果 context.system_scope 和 context.project_id 不为 None，则填充相同的标头 (HTTP_X_PROJECT_ID)。这对于服务到服务通信很重要（例如，nova 使用用户的上下文对象与 neutron 通信以进行端口绑定，以便为特定项目构建服务器）。

依赖项¶

无

文档影响¶

需要更新文档以指定何时允许传递项目 ID 值。

参考资料¶

[1] https://etherpad.opendev.org/p/policy-popup-xena-ptg [2] https://bugs.launchpad.net/nova/+bug/1918945

secure-rbac - X-Project-Id 传递