默认服务角色¶

bug #1951632

在 Rocky 版本中，keystone 添加了一个默认角色层级。这是更大规模改进所有 OpenStack 项目中 RBAC 的一部分。在采用 Rocky 中实现的默认角色过程中，OpenStack 开发者和运维人员已经认识到，多个 OpenStack 服务帐户拥有过多的授权。

本规范详细说明了创建名为 service 的新角色，以及更新 OpenStack 中的默认策略的原因，以便服务之间的通信使用该专用角色。

问题描述¶

目前，keystone-manage bootstrap 提供了三个默认角色，admin、member 和 reader。这些角色构建了一个基本层级，其中 admin 意味着 member，而 member 意味着 reader。这项工作背后的原理在原始规范中详细说明。

admin 角色拥有在 OpenStack 部署中执行几乎任何操作的能力。不幸的是，它被用作授权的万能选项。这导致服务用户在需要在某个服务中执行特权操作时获得 admin 角色。实际上，这是一种糟糕的安全实践，因为该服务帐户有能力执行任何操作。它可以创建、更新和删除部署中的任何资源。恶意行为者可以轻松利用受损的服务帐户创建到部署的后门访问权限。

通过将最小权限原则应用于服务用户，我们可以加强 OpenStack 默认的安全态势并减少管理权限的范围。

提议的变更¶

扩展 keystone-manage bootstrap 工具，以创建一个名为 service 的新角色。应优雅地处理冲突，尤其因为 OpenStack 中的一些策略已经依赖于 service 角色，并且运维人员很可能已经创建了这个角色。不应删除然后重新创建现有角色，以免破坏依赖于该角色 ID 的任何内容。

此角色应保留在现有角色层级之外，该层级包括 admin、member 和 reader。这些角色定义是为人类设计的，并按层级组织以应用于层级 RBAC。服务之间的通信更加明确，服务帐户只需要访问其他服务的少量 API。在当前层级之外构建 service 角色可确保我们遵循服务帐户的最小权限原则。

在 keystone 实现对 service 角色的支持后，OpenStack 服务开发者可以开始将其集成到他们的默认策略中。

policy.DocumentedRuleDefault(
    name='os_compute_api:os-server-external-events:create',
    check_str='role:service',
    scope_types=['project']
)

我们需要保持所有服务到服务 API 默认只使用 service 角色，并且不在逻辑或此处添加任何其他角色。这里的想法是保持它们对 service 角色的默认访问权限。如果任何服务到服务 API 被管理员或非管理员用户使用，建议他们覆盖 policy.yaml 文件中的默认设置，而不是更改代码中的默认设置。如果某些服务到服务 API 被项目认为对管理员或非管理员用户有用，那么他们可以做出例外决定，将它们默认为用户角色和 service 角色。

由于我们已经放弃了服务的系统范围实现，因此使用项目范围令牌进行服务到服务的通信将使用 service 角色。

此外，任何为 OpenStack 服务创建服务帐户的部署工具都应开始为这些策略更改做准备，方法是更新其角色分配并执行部署语言等效的操作

$ openstack role add --user nova --project service service
$ openstack role add --user cinder --project service service
$ openstack role add --user neutron --project service service
$ openstack role add --user glance  --project service service
$ openstack role add --user manila  --project service service

未来工作建议¶

特定于服务默认角色¶

在后续版本中，我们可以进一步阐述这个概念，创建其他角色，例如 compute-service、block-storage-service、network-service、image-service 等。 service 角色可以意味着这些角色中的每一个，并且每个服务的策略可以再次被完善，以便只允许基于服务的访问。这将需要额外的部署工具干预

$ openstack role add --user nova --project service compute-service
$ openstack role add --user cinder --project service block-storage-service
$ openstack role add --user neutron --project service network-service
$ openstack role add --user glance --project service image-service

这将减少服务帐户与它们不需要的 API 交互的能力。

应用程序凭据¶

特定于服务的默认角色的替代方案是使用具有访问规则的应用程序凭据为每个服务。每个服务仍然将拥有 service 角色，但它将被限制为仅使用访问规则访问它需要的 API。

备选方案¶

我们可以依赖部署工具在安装时部署此角色。但是，这仍然会给 OpenStack 安装程序带来不一致性。

在 keystone-manage bootstrap 中添加正式支持更简洁、更一致，并与现有部署工具集成，而无需额外操作。

安全影响¶

这个新角色已经被 OpenStack 中的一些策略使用。最初使用它比授予服务用户 admin 角色更好。

通知影响¶

无

其他最终用户影响¶

这项工作不需要任何客户端代码，因为它使用 keystone-manager 完成。

性能影响¶

这只是在角色表中添加另一行，是一个微不足道的更改。性能影响可以忽略不计。

其他部署者影响¶

如果运维人员或部署人员有一个创建 service 角色的工具，那么他们可以更新该工具以删除该 API 调用，并且他们可以依赖于 keystone-manage bootstrap 中的功能。

开发人员影响¶

开发者将拥有另一个角色可供编写默认策略。他们应该了解 service 的正确用法，并且它应该仅用于服务到服务的 API。

实现¶

负责人¶

主要负责人: <lbragstad> <abhishekk>

工作项¶

更新 keystone-manage bootstrap 以创建一个名为 service 的新角色
将相应的 service 角色添加到管理员指南
将 service 角色添加到开发者文档
将服务角色添加到描述安全 RBAC 角色的任何 OpenStack 范围的文档

依赖项¶

这项工作是为推进一套社区范围内的目标以改进 OpenStack 中的授权而必需的。

文档影响¶

如工作项目部分中列出。

参考资料¶

内联引用。

默认服务角色