Add identity spec for domain-manager persona
Partial-Bug: #2045974 Co-Authored-By: Josephine Seifert <josephine.seifert@cloudandheat.com> Change-Id: I787972e560f70fc56a99c44198e509222fe5ad16
This commit is contained in:
Markus Hentsch
Josephine Seifert
parent
330200b4d8
commit
557adfa072
|
|
@ -0,0 +1,249 @@
|
|||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
====================================================================
|
||||
Domain Manager Persona for domain-scoped self-service administration
|
||||
====================================================================
|
||||
|
||||
`bug #2045974 <https://bugs.launchpad.net/keystone/+bug/2045974>`_
|
||||
|
||||
In scenarios where customers are assigned a whole domain, they might desire
|
||||
self-service functionality for managing users, projects and groups within that
|
||||
domain.
|
||||
The `Consistent and Secure Default RBAC
|
||||
<https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html>`_
|
||||
introduced the ``manager`` role for projects as a customer-side management role
|
||||
between ``admin`` and ``member`` but added no such role model for domains.
|
||||
This specification introduces a new ``domain-manager`` persona to fill that gap
|
||||
and enables domain-scoped identity self-service capabilities for customers.
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
Today, you need the ``admin`` role in keystone in order to fully manage groups,
|
||||
projects and users including their role assignments. Since this role is
|
||||
intended for the highest level of authorization, it is usually reserved for
|
||||
operators. This means that even if a customer is confined within a domain in
|
||||
Keystone, they need to involve operators of the cloud to have users, projects
|
||||
and groups as well as corresponding role assignments managed for them.
|
||||
|
||||
For customers receiving a whole domain in Keystone this is often unsatisfactory
|
||||
since a self-service capability is desired. For instance, a customer might want
|
||||
to align Keystone projects with their departments and on-/offboard
|
||||
corresponding staff as Keystone users on their own.
|
||||
|
||||
For this purpose a role or persona and corresponding set of permissions are
|
||||
required which implement this management functionality for customers.
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
Adjust existing policy defaults to incorporate the domain-scoped ``manager``
|
||||
role accordingly like described below.
|
||||
|
||||
The ``domain-manager`` persona should be exclusive to Keystone for managing
|
||||
identity objects such as users, projects and groups along with role assignments
|
||||
within a domain to enable identity management self-service for end users.
|
||||
|
||||
All default policies that concern users, projects, groups and roles in the
|
||||
Identity API have to be adjusted to incorporate the ``domain-manager`` persona
|
||||
on a domain level.
|
||||
Below is an example of the `identity:create_project` policy adjusted for the
|
||||
``domain-manager`` persona. It adjusts the domain-scoped check to accept the
|
||||
``manager`` role instead of ``admin``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# for the second part of the folllowing "or" conditional "role:admin" has
|
||||
# been replaced by "role:manager"
|
||||
SYSTEM_ADMIN_OR_DOMAIN_ADMIN = (
|
||||
'(role:admin and system_scope:all) or '
|
||||
'(role:manager and domain_id:%(target.project.domain_id)s)'
|
||||
)
|
||||
|
||||
# policy defintions using this definition stay the same, for example
|
||||
# the "identity:create_project" rule:
|
||||
policy.DocumentedRuleDefault(
|
||||
name=base.IDENTITY % 'create_project',
|
||||
check_str=SYSTEM_ADMIN_OR_DOMAIN_ADMIN,
|
||||
scope_types=['system', 'domain'],
|
||||
description='Create project.',
|
||||
operations=[{'path': '/v3/projects',
|
||||
'method': 'POST'}],
|
||||
deprecated_rule=deprecated_create_project),
|
||||
|
||||
One crucial part of a domain manager's responsibility will be to assign roles
|
||||
within a domain. For this purpose, the existing rule defaults in Keystone can
|
||||
be repurposed:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# below "role:admin" has been replaced by "role:manager"
|
||||
GRANTS_DOMAIN_ADMIN = (
|
||||
'(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 stays the same
|
||||
SYSTEM_ADMIN_OR_DOMAIN_ADMIN = (
|
||||
'(' + base.SYSTEM_ADMIN + ') or '
|
||||
'(' + GRANTS_DOMAIN_ADMIN + ') and '
|
||||
'(' + DOMAIN_MATCHES_ROLE + ')'
|
||||
)
|
||||
|
||||
However, a domain manager should not be able to assign roles of higher
|
||||
privileges than themselves, so the set of target roles they are able to
|
||||
assign/revoke should be restricted using a new rule. Defining this as a rule
|
||||
offers the advantage that operators or deployers may easily adjust this role
|
||||
list (which roles are manageable) without the need to rewrite the whole set of
|
||||
lenghty individual rules for all the API actions:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# define a new rule called "domain_managed_target_role"
|
||||
policy.RuleDefault(
|
||||
name='domain_managed_target_role',
|
||||
check_str="'member':%(target.role.name)s or "
|
||||
"'reader':%(target.role.name)s"),
|
||||
|
||||
Finally, all the rules that concern role grants should be adjusted to
|
||||
incorporate this target role restriction. Below is an example for
|
||||
``identity:create_grant``:
|
||||
|
||||
.. code-block:: python
|
||||
|
||||
# here a "and rule:domain_managed_target_role" is added to the check
|
||||
policy.DocumentedRuleDefault(
|
||||
name=base.IDENTITY % 'create_grant',
|
||||
check_str=(SYSTEM_ADMIN_OR_DOMAIN_ADMIN +
|
||||
' and rule:domain_managed_target_role'),
|
||||
scope_types=['system', 'domain'],
|
||||
|
||||
The changes illustrated above need to be applied to all applicable policy
|
||||
definitions that handle relationships between users, projects, groups and roles
|
||||
within domains accordingly.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
A new role: ``domain-manager`` could also be used for this purpose.
|
||||
The positive aspect would be a better differenciation between the ``manager``
|
||||
on a project level and a ``manager`` on a domain level. For an end user it
|
||||
might be more obvious which of the two use cases they have been assigned the
|
||||
role for without looking up the assignment scope by themselves.
|
||||
But a new ``domain-manager`` role would not fit into the new RBAC system, that
|
||||
requires the roles to be hierarchically structured, when they can be assigned
|
||||
to a user.
|
||||
|
||||
Another alternative would be to assign the ``admin`` role to end users within
|
||||
domains in a scoped fashion like the current rule defaults imply. However, the
|
||||
``admin`` role does not seem be properly scoped across all OpenStack services
|
||||
(see `this Launchpad bug <https://bugs.launchpad.net/keystone/+bug/968696>`_).
|
||||
Furthermore, `there has been operator
|
||||
feedback <https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#the-issues-we-are-facing-with-scope-concept>`_
|
||||
that a scoped ``admin`` role is a confusing concept in general. It seems to be
|
||||
more appropriate to introduce a dedicated role for this, akin to the
|
||||
``manager`` role for projects.
|
||||
|
||||
Security Impact
|
||||
---------------
|
||||
|
||||
The ``domain-manager`` persona will allow customers to have administrative
|
||||
management capabilities for users, projects, groups and role assignments within
|
||||
a domain. However, the persona must first be assigned to a customer
|
||||
user by an operator. This is a deliberate action by the operator and customers
|
||||
do not get the persona or its permission set by default.
|
||||
|
||||
Using the ``domain-manager`` persona will be better than granting customers the
|
||||
``admin`` role in their domain.
|
||||
|
||||
Notifications Impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other End User Impact
|
||||
---------------------
|
||||
|
||||
This work doesn't require any client code.
|
||||
|
||||
End users receiving the new ``domain-manager`` persona within a domain can
|
||||
start using its permission set right away.
|
||||
|
||||
Performance Impact
|
||||
------------------
|
||||
|
||||
This is a trivial change to add another RBAC-persona and corresponding
|
||||
policy definitions. Performance impact is negligible.
|
||||
|
||||
Other Deployer Impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer Impact
|
||||
----------------
|
||||
|
||||
As this persona is intended for runtime usage, the only impact for developers
|
||||
is to watch closely when adding new policies for the ``manager`` role, to avoid
|
||||
accidently giving privileges to the domain-scoped ``manager``.
|
||||
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
None
|
||||
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
* Adjust the default policies for group, project, user and role management
|
||||
actions in Keystone to incorporate the new domain-scoped ``manager`` in a way
|
||||
that enables management rights in domain scope only
|
||||
* Add the ``domain-manager`` persona to the Keystone documentation describing
|
||||
its purpose and usage
|
||||
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
Any documentation that concerns identity management and Keystone usage should
|
||||
include instructions for the ``domain-manager`` persona where appropriate.
|
||||
This will be more or less restricted to Keystone since this persona is only of
|
||||
use for the Identity API.
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
* `Draft of the Domain Manager
|
||||
standard <https://github.com/SovereignCloudStack/standards/blob/main/Standards/scs-0302-v1-domain-manager-role.md>`_
|
||||
implementing the concept in Sovereign Cloud Stack using separate Keystone
|
||||
policy adjustments based on the current defaults
|
||||
* `Etherpad notes from Caracal vPTG of Keystone discussing the topic and
|
||||
initiating this spec <https://etherpad.opendev.org/p/caracal-ptg-keystone>`_
|
||||
* `Consistent and Secure RBAC: project manager role <https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rbac.html#implement-support-for-project-manager-personas>`_
|
||||
* `Launchpad bug: "admin"-ness not properly scoped <https://bugs.launchpad.net/keystone/+bug/968696>`_
|
||||
Loading…
Reference in New Issue