默认角色¶
简介¶
与大多数 OpenStack 服务一样,keystone 使用基于角色的访问控制 (RBAC) 来保护其 API。
用户可以根据他们在项目、域或系统上拥有的角色访问不同的 API,我们将其称为范围。
从 Rocky 版本开始,keystone 默认提供三个角色,分别为 admin、member 和 reader。操作员可以将这些角色授予任何 actor(例如,组或用户)在任何范围(例如,系统、域或项目)上。如果您需要复习授权范围和令牌类型,请参阅 令牌指南。以下章节描述了每个默认角色在不同范围内与 keystone 的 API 交互的方式。此外,其他服务开发人员可以将本文档作为指南,以在他们的服务中实现类似的模式。
跨范围的默认角色和行为允许操作员将其功能委托给他们的团队、审计员、客户和用户,而无需维护自定义策略。
除了 admin、member 和 reader 角色之外,从 2023.2 (Bobcat) 版本开始,keystone 默认还将提供 service 和 manager 角色。操作员可以使用 service 角色进行服务到服务的 API 调用,而不是对相同目的使用 admin 角色。service 角色将与 admin、member、reader 分开,并且不会影响这些角色。操作员可以将 manager 角色授予域内的用户,以启用对其域内的用户、组、项目和角色分配的自助管理。
角色定义¶
keystone 通过 keystone-manage bootstrap 提供的默认角色(service 角色除外)通过角色含义相关联。admin 角色意味着 manager 角色,manager 意味着 member 角色,member 角色意味着 reader 角色。这些含义意味着拥有 admin 角色的用户会自动拥有 manager、member 和 reader 角色。此外,拥有 manager 角色的用户会自动拥有 member 和 reader 角色。拥有 member 角色的用户会自动拥有 reader 角色。角色含义减少了角色分配,并形成了默认角色之间的自然层次结构。它还通过使检查字符串更短来降低默认策略的复杂性。例如,需要 reader 的策略可以表示为
"identity:list_foo": "role:reader"
代替
"identity:list_foo": "role:admin or role:manager or role:member or role:reader"
读者¶
警告
虽然可以使用 reader 角色执行审计,但我们强烈建议从您正在追求的合规目标的角度评估使用 reader 进行审计的可行性。
这里描述的角色层次结构中,reader 角色是权限最低的角色。因此,OpenStack 开发团队默认情况下不提倡将敏感信息暴露给拥有 reader 角色的用户,无论范围如何。我们注意到需要一个正式的、只读的、对检查特定范围内所有适用资源有用角色的需求,但不应将其实现为授权的最低级别。这项工作将在后续版本中进行,届时我们将支持一个提升的只读角色,该角色意味着 reader,但也会在适用时暴露敏感信息。
这将允许操作员授予第三方审计员一个允许查看敏感信息的权限角色,特别是对于需要它的合规目标。
reader 角色提供对系统、域或项目内资源的只读访问权限。根据分配范围,拥有 reader 角色的两个用户可以期望不同的 API 行为。例如,拥有系统上 reader 角色的用户可以列出部署中的所有项目。拥有域上 reader 角色的用户只能列出其域内的项目。
通过分析角色的分配范围,我们提高了 reader 角色的可重用性,并在不引入更多角色的情况下提供了更大的功能。例如,为了实现这一点,而无需分析分配范围,您需要 system-reader、domain-reader 和 project-reader 角色以及每个服务的自定义策略。
重要的是要注意,reader 是层次结构中权限最低的角色,因为使用 admin 或 member 进行的分配最终包含 reader 角色。我们明确记录这一点,以便不要用只读访问敏感信息来重载 reader 角色。例如,为了特定的合规目标而进行的部署,可能希望利用 reader 角色进行审计。如果审计需要审计员评估给定范围内的敏感信息,例如许可证密钥或管理元数据,则审计员不应期望使用 reader 角色执行这些操作。我们证明了此设计决策,因为敏感信息应受到明确保护,而不是隐式暴露。
应从最小权限的角度实现和使用 reader 角色,这可能或可能不满足您的审计用例。
成员¶
在 keystone 中,拥有 member 角色与拥有 reader 角色相比,没有明显的优势。member 角色更适用于其他服务。 member 角色非常适合在 admin 和 reader 角色之间引入粒度。其他服务可能会编写默认策略,要求 member 角色才能创建资源,但 admin 角色才能删除它们。例如,拥有项目上 reader 角色的用户可以列出实例,拥有项目上 member 角色的用户可以列出和创建实例,而拥有项目上 admin 角色的用户可以列出、创建和删除实例。服务开发人员可以使用 member 角色在不同范围内提供 admin 和 reader 之间的更多灵活性。
管理器¶
manager 角色在 keystone 中占据特殊的位置。它位于 admin 和 member 角色之间,允许有限的身份管理,同时在目的和权限方面与 admin 角色有明显的区别。manager 角色旨在在域范围内分配,并允许用户管理整个域中的身份资产,包括用户、项目、组和角色分配。这使得域内用户能够进行身份自助管理,而无需将最特权的 admin 角色分配给他们。
keystone 默认策略包括一个特殊规则,该规则指定拥有 manager 角色的用户可以在域范围内分配和撤销的角色列表。这可以防止此类用户升级他们自己或他人的权限到 manager 以上,为此目的,该列表排除了 admin 角色。如果角色模型不同,可以通过策略定义由云管理员调整该列表。例如,如果为特定云环境引入了新角色,则可以调整该列表以允许拥有 manager 角色的用户也分配它。
其他服务可能会编写默认策略以允许 manager 角色在域中拥有更多特权的管理权限或跨项目权限。
管理员¶
我们为给定范围内的最特权操作保留 admin 角色。重要的是要注意,在项目、域或系统上拥有 admin 权限具有单独的授权,并且不具有传递性。例如,拥有系统上 admin 角色的用户应该能够管理部署的各个方面,因为他们是操作员。拥有项目上 admin 角色的用户不应该能够管理项目之外的内容,因为这将违反其角色分配的租户关系(由于服务正在各自的节奏解决此问题,因此这并不一致)。
服务¶
我们为服务到服务的通信保留 service 角色。service 角色的目的是允许一个服务与另一个服务通信,并可能由接收请求的服务授予更高的权限。在引入 service 角色之前,服务必须授予 admin 角色才能拥有更高的权限,这赋予了服务远超必要的权限。有了 service 角色,我们现在可以允许所有服务到服务的 API 默认仅使用 service 角色。例如,需要 service 的策略可以表示为
"identity:create_foo": "role:service"
可能存在项目认为对管理员或非管理员用户有用而可以例外地使用它们的服务到服务的 API,然后他们可以例外地将它们默认为用户角色和 service 角色。例如,需要 service 和 admin 的策略可以表示为
"identity:create_foo": "role:service or role:admin"
注意
与其它默认角色不同,service 角色不是角色层次结构的一部分。它是一个独立的角色。
注意
从 Train 版本开始,keystone 在其 API 中一致地应用以下角色。
系统角色¶
本节描述了通常用于操作员和部署者的授权角色。您可以使用以下查询找到具有系统角色分配的所有用户
$ openstack role assignment list --names --system all
+--------+------------------------+------------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------------------------+------------------------+---------+--------+--------+-----------+
| admin | | system-admins@Default | | | all | False |
| admin | admin@Default | | | | all | False |
| admin | operator@Default | | | | all | False |
| reader | | system-support@Default | | | all | False |
| member | system-support@Default | | | | all | False |
+--------+------------------------+------------------------+---------+--------+--------+-----------+
系统管理员¶
系统管理员 允许管理 keystone 中的每个资源。系统管理员通常是操作员和云管理员。他们可以控制最终影响部署行为的资源。例如,他们可以在目录中添加或删除服务和端点,创建新域,添加联合映射,以及清理过时的资源,例如用户的应用程序凭据或信任关系。
您可以使用以下分配找到您的部署中的系统管理员
$ openstack role assignment list --names --system all --role admin
+-------+------------------+-----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+------------------+-----------------------+---------+--------+--------+-----------+
| admin | | system-admins@Default | | | all | False |
| admin | admin@Default | | | | all | False |
| admin | operator@Default | | | | all | False |
+-------+------------------+-----------------------+---------+--------+--------+-----------+
系统成员和系统读者¶
在 keystone 中,系统成员 和 系统读者 非常相似,并且具有相同的授权。拥有系统上这些角色的用户可以查看 keystone 中的所有资源。他们可以列出角色分配、用户、项目和组会员资格等资源。
如果审计不需要访问敏感信息,系统读者 角色对支持团队或审计员的成员很有用。您可以使用以下分配找到您的部署中的系统成员 和 系统读者
$ openstack role assignment list --names --system all --role member --role reader
+--------+------------------------+------------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------------------------+------------------------+---------+--------+--------+-----------+
| reader | | system-support@Default | | | all | False |
| admin | operator@Default | | | | all | False |
| member | system-support@Default | | | | all | False |
+--------+------------------------+------------------------+---------+--------+--------+-----------+
警告
过滤系统角色分配目前已损坏,并正在跟踪为 bug。
域角色¶
本节描述了管理自己的域的角色的授权角色,这些域包含项目、用户和组。您可以使用以下查询找到特定域上具有角色分配的所有用户
$ openstack role assignment list --names --domain foobar
+---------+-----------------+----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+---------+-----------------+----------------------+---------+--------+--------+-----------+
| reader | support@Default | | | foobar | | False |
| admin | jsmith@Default | | | foobar | | False |
| admin | | foobar-admins@foobar | | foobar | | False |
| manager | alice@foobar | | | foobar | | False |
| member | jdoe@foobar | | | foobar | | False |
+---------+-----------------+----------------------+---------+--------+--------+-----------+
域管理员¶
域管理员 可以管理域或其内容的大部分方面。这些用户可以在其域内创建新项目和用户。他们可以检查用户在其域内的项目上拥有的角色分配。
域管理员 不允许访问系统特定资源或其域之外的资源。需要控制项目、组和用户创建的用户非常适合域管理员。
您可以使用以下角色分配找到您的部署中的域管理员
$ openstack role assignment list --names --domain foobar --role admin
+-------+----------------+----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+----------------+----------------------+---------+--------+--------+-----------+
| admin | jsmith@Default | | | foobar | | False |
| admin | | foobar-admins@foobar | | foobar | | False |
+-------+----------------+----------------------+---------+--------+--------+-----------+
域管理器¶
域管理员只能管理与其域内身份管理相关的特定资源。这包括创建、更新和删除新用户、项目和组。他们还可以分配和撤销这些资源或与域相关的角色。此外,他们可以检查域内的角色分配情况。
域管理员不能更改域本身的任何方面。他们可以在其域内应用的角色分配仅限于特定的适用角色列表,并且在默认配置下,这排除了 admin 角色,以防止权限提升。
您可以使用以下角色分配在您的部署中找到域管理员
$ openstack role assignment list --names --domain foobar --role manager
+---------+-----------------+----------------------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+---------+-----------------+----------------------+---------+--------+--------+-----------+
| manager | alice@foobar | | | foobar | | False |
+---------+-----------------+----------------------+---------+--------+--------+-----------+
域成员 & 域读者¶
域成员和域读者与系统成员和系统读者具有相同关系。他们被允许查看其域的资源和信息。他们不允许访问系统特定的信息或域外项目、组和用户的信息。
域成员和域读者用例非常适合支持团队、监控帐户的详细信息或审计域内的资源,假设审计不验证敏感信息。您可以使用以下角色分配找到域成员和域读者
$ openstack role assignment list --names --role member --domain foobar
+--------+-------------+-------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+-------------+-------+---------+--------+--------+-----------+
| member | jdoe@foobar | | | foobar | | False |
+--------+-------------+-------+---------+--------+--------+-----------+
$ openstack role assignment list --names --role reader --domain foobar
+--------+-----------------+-------+---------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+-----------------+-------+---------+--------+--------+-----------+
| reader | support@Default | | | foobar | | False |
+--------+-----------------+-------+---------+--------+--------+-----------+
项目角色¶
本节描述了在项目内操作的用户授权角色。这些角色通常由最终用户使用。您可以使用以下查询找到具有特定项目角色分配的所有用户
$ openstack role assignment list --names --project production
+--------+----------------+----------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+----------------+----------------------------+-------------------+--------+--------+-----------+
| admin | jsmith@Default | | production@foobar | | | False |
| admin | | production-admins@foobar | production@foobar | | | False |
| member | | foobar-operators@Default | production@foobar | | | False |
| reader | alice@Default | | production@foobar | | | False |
| reader | | production-support@Default | production@foobar | | | False |
+--------+----------------+----------------------------+-------------------+--------+--------+-----------+
项目管理员¶
项目管理员只能查看和修改其具有授权的项目内的的数据。他们能够查看其项目的信息并在其项目上设置标签。他们不允许查看系统或域资源,因为这会违反其角色分配的租户关系。由于 Keystone API 中的大多数资源都是系统和域特定的,因此项目管理员没有太多授权。
您可以使用以下角色分配在您的部署中找到项目管理员
$ openstack role assignment list --names --project production --role admin
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
| admin | jsmith@Default | | production@foobar | | | False |
| admin | | production-admins@foobar | production@foobar | | | False |
+-------+----------------+--------------------------+-------------------+--------+--------+-----------+
项目成员 & 项目读者¶
项目成员和项目读者可以发现其项目的信息。他们可以访问重要信息,例如其项目的资源限制,但他们不允许查看项目外部的信息或查看系统特定的信息。
您可以使用以下角色分配在您的部署中找到项目成员和项目读者
$ openstack role assignment list --names --project production --role member
+--------+------+--------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+------+--------------------------+-------------------+--------+--------+-----------+
| member | | foobar-operators@Default | production@foobar | | | False |
+--------+------+--------------------------+-------------------+--------+--------+-----------+
$ openstack role assignment list --names --project production --role reader
+--------+---------------+----------------------------+-------------------+--------+--------+-----------+
| Role | User | Group | Project | Domain | System | Inherited |
+--------+---------------+----------------------------+-------------------+--------+--------+-----------+
| reader | alice@Default | | production@foobar | | | False |
| reader | | production-support@Default | production@foobar | | | False |
+--------+---------------+----------------------------+-------------------+--------+--------+-----------+
编写策略¶
如果上述粒度无法满足您的特定用例,您仍然可以覆盖策略并手动维护它们。您可以在 oslo.policy 用法 文档中了解更多信息。