域管理器角色，用于域范围内的自助管理

bug #2045974

在将整个域分配给客户的场景中，他们可能希望拥有自助功能来管理该域内的用户、项目和组。 一致且安全的默认 RBAC 引入了项目中的 manager 角色，作为客户侧管理角色，介于 admin 和 member 之间，但未为域添加类似的角色模型。 本规范引入了一个新的 domain-manager 角色，以填补这一空白，并为客户启用域范围内的身份自助服务能力。

问题描述

目前，您需要 keystone 中的 admin 角色才能完全管理组、项目和用户，包括它们的角色分配。 由于此角色旨在用于最高级别的授权，因此通常保留给操作员。 这意味着即使客户在 Keystone 中被限制在某个域内，他们也需要让云的操作员来管理用户、项目和组以及相应的角色分配。

对于获得 Keystone 中整个域的客户来说，这通常是不令人满意的，因为期望的是自助服务能力。 一个用例示例是“虚拟私有云”(VPC) 方法，即公共云的操作员希望将经销商域分配给客户，然后客户可以在自助服务的基础上细分这些域。

为此，需要一个角色或角色定义以及相应的权限集，以实现客户的管理功能。

提议的变更

相应地调整现有的策略默认值，以包含域范围内的 manager 角色，如下面所述。

应在 Keystone 中实现 domain-manager 角色，以管理身份对象，例如用户、项目和组，以及域内的角色分配，从而为最终用户启用身份管理自助服务。

所有涉及用户、项目、组和角色的 Identity API 的默认策略都需要进行调整，以在域级别包含 domain-manager 角色。 以下是 identity:create_project```policy 调整 为 ``domain-manager 角色的示例。 它调整了检查，以除了 admin 之外，还接受域范围内的 manager 角色。

# this extends the current default (base.RULE_ADMIN_REQUIRED) by
# the domain-scoped manager
ADMIN_OR_DOMAIN_MANAGER = (
    '(' + base.RULE_ADMIN_REQUIRED + ') or '
    '(role:manager and domain_id:%(target.project.domain_id)s)'
)

# policy defintions concerning the management of users, projects, groups
# and role assignments have to be adjusted to use this new rule,
# for example the "identity:create_project" rule:
policy.DocumentedRuleDefault(
    name=base.IDENTITY % 'create_project',
    check_str=ADMIN_OR_DOMAIN_MANAGER,
    scope_types=['system', 'domain', 'project'],
    description='Create project.',
    operations=[{'path': '/v3/projects',
                 'method': 'POST'}],
    deprecated_rule=deprecated_create_project),

对于处理多个目标资源的操作，需要添加额外的检查，以确保域管理器只能访问相同域的资源。 以下示例说明了组策略文件中的 add_user_to_group 策略定义的实现方式

# copied over from grant.py
DOMAIN_MATCHES_USER_DOMAIN = 'domain_id:%(target.user.domain_id)s'
DOMAIN_MATCHES_GROUP_DOMAIN = 'domain_id:%(target.group.domain_id)s'

# new rule for domain managers for user and group resources within domain
DOMAIN_MANAGER_AND_DOMAIN_SCOPED_USER_GROUP_TARGETS = (
    '(role:manager and ' + DOMAIN_MATCHES_USER_DOMAIN + ' and'
    ' ' + DOMAIN_MATCHES_GROUP_DOMAIN + ')'
)

# the following policy definition has been modified to extend check_str
# by the new rule introduced above
policy.DocumentedRuleDefault(
   name=base.IDENTITY % 'add_user_to_group',
   check_str='(' + base.RULE_ADMIN_REQUIRED + ') or ' +
             DOMAIN_MANAGER_AND_DOMAIN_SCOPED_USER_GROUP_TARGETS,
   scope_types=['system', 'domain', 'project'],
   description='Add user to group.',
   operations=[{'path': '/v3/groups/{group_id}/users/{user_id}',
                'method': 'PUT'}],
   deprecated_rule=deprecated_add_user_to_group)

域管理器职责的一个重要部分将是在域内分配角色。 为此，可以重用 Keystone 中现有的规则默认值

# below "GRANTS_DOMAIN_ADMIN" has been renamed to "GRANTS_DOMAIN_MANAGER"
# and "role:admin" has been replaced by "role:manager"
GRANTS_DOMAIN_MANAGER = (
    '(role:manager and ' + DOMAIN_MATCHES_USER_DOMAIN + ' and'
    ' ' + DOMAIN_MATCHES_PROJECT_DOMAIN + ') or '
    '(role:manager and ' + DOMAIN_MATCHES_USER_DOMAIN + ' and'
    ' ' + DOMAIN_MATCHES_TARGET_DOMAIN + ') or '
    '(role:manager and ' + DOMAIN_MATCHES_GROUP_DOMAIN + ' and'
    ' ' + DOMAIN_MATCHES_PROJECT_DOMAIN + ') or '
    '(role:manager and ' + DOMAIN_MATCHES_GROUP_DOMAIN + ' and'
    ' ' + DOMAIN_MATCHES_TARGET_DOMAIN + ')'
)

# the following has been renamed from "ADMIN_OR_DOMAIN_ADMIN" to
# "ADMIN_OR_DOMAIN_MANAGER" to reflect the changed behavior
ADMIN_OR_DOMAIN_MANAGER = (
    '(' + base.SYSTEM_ADMIN + ') or '
    '(' + GRANTS_DOMAIN_MANAGER + ') and '
    '(' + DOMAIN_MATCHES_ROLE + ')'
)

但是，域管理器不应能够分配比自身更高权限的角色，因此他们能够分配/撤销的角色集应使用新规则进行限制。 将其定义为规则的优点是，操作员或部署者可以轻松调整此角色列表（哪些角色可管理），而无需重写所有 API 操作的整个规则集。

# define a new rule called "domain_managed_target_role"
policy.RuleDefault(
    name='domain_managed_target_role',
    check_str="'manager':%(target.role.name)s or "
              "'member':%(target.role.name)s or "
              "'reader':%(target.role.name)s"),

最后，应调整所有涉及角色授予的规则，以包含此目标角色限制。 以下是 identity:create_grant 的示例

# here a "and rule:domain_managed_target_role" is added to the check
policy.DocumentedRuleDefault(
    name=base.IDENTITY % 'create_grant',
    check_str=(ADMIN_OR_DOMAIN_MANAGER +
               ' and rule:domain_managed_target_role'),
    scope_types=['system', 'domain'],

上述更改需要应用于所有适用的策略定义，这些定义以相应的方式处理域内用户、项目、组和角色之间的关系。

本规范不涉及 Keystone 以外的服务。 在 Keystone 中引入角色定义和角色为 domain-manager 角色在其他服务（例如 Nova 或 Cinder）中建立奠定了基础。 但是，domain-manager 角色的预期目的和结果权限集高度依赖于服务，由相应的项目定义和实现。 对于 Keystone 而言，这仅涉及域级别的身份管理，这是本规范的范围。 其他服务将来可能会采用 domain-manager 角色。

备选方案

也可以使用一个新的角色：domain-manager 来实现此目的。 积极的一方面是更好地区分项目级别的 manager 和域级别的 manager。 对于最终用户来说，在无需自行查找分配范围的情况下，他们被分配了哪个用例的角色可能更明显。 但是，新的 domain-manager 角色不符合新的 RBAC 系统，该系统要求角色在可以分配给用户时具有分层结构。

另一种选择是在域内以类似于当前规则默认值的方式，以范围方式将 admin 角色分配给最终用户。 但是，admin 角色似乎并未在所有 OpenStack 服务中正确范围化（请参阅 此 Launchpad 错误）。 此外，有操作员反馈 指出，范围化的 admin 角色通常是一个令人困惑的概念。 似乎引入一个专门的角色更合适，类似于项目级别的 manager 角色。

安全影响

domain-manager 角色将允许客户在域内对用户、项目、组和角色分配进行管理管理能力。 但是，必须首先由操作员将该角色分配给客户用户。 这是操作员的有意行为，客户默认情况下不会获得该角色或其权限集。

使用 domain-manager 角色比在域内授予客户 admin 角色更好。

通知影响

无

其他最终用户影响

这项工作不需要任何客户端代码。

收到域内新的 domain-manager 角色的最终用户可以立即开始使用其权限集。

性能影响

这是一个微不足道的更改，可以添加另一个 RBAC 角色和相应的策略定义。 性能影响可以忽略不计。

其他部署者影响

无

开发人员影响

由于此角色旨在用于运行时使用，因此开发人员的唯一影响是在添加新的 manager 角色策略时密切关注，以避免意外地授予域范围的 manager 权限。

实现

负责人

主要负责人

无

其他贡献者

无

工作项

  • 调整 Keystone 中组、项目、用户和角色管理操作的默认策略，以包含新的域范围内的 manager，从而以仅在域范围内启用管理权限的方式。

  • 将 domain-manager 角色添加到 Keystone 文档中，描述其目的和用法

依赖项

无

文档影响

任何涉及身份管理和 Keystone 使用的文档都应在适当的情况下包含有关 domain-manager 角色的说明。 这或多或少仅限于 Keystone，因为此角色仅对 Identity API 有用。

参考资料