Allow project roles to be inherited from owning domain
With the Identity v3 API we removed the concept of a global admin for use within keystone's policy file. However, there are situations were the current capabilities are not sufficient. The classic example is when a Cloud Provider uses a Domain for each of their customers and enables customer admins to manage their own users, groups and projects. However, the cloud provider would like to ensure that they maintain some specific admin roles across all their customers' projects (perhaps so that they could do things like evacuate VMs from a machine for maintenance). How can they ensure such a role is always added to such projects? Right now they would have to rely on the customer who created the project adding the appropriate roles for the cloud provider.
A solution would be to allow a role assigned to a domain to optionally be able to be inherited by the owned projects. That way a cloud provider could assign, for example, a maintenance-role to an admin user (or group) on each domain they create, which would be automatically be included in a token they scoped to any project for issuing maintenance commands.
Identity API changes proposed can be found here: https:/
Blueprint information
- Status:
- Complete
- Approver:
- Henry Nash
- Priority:
- High
- Drafter:
- Henry Nash
- Direction:
- Approved
- Assignee:
- Henry Nash
- Definition:
- Approved
- Series goal:
- Accepted for havana
- Implementation:
-
Implemented
- Milestone target:
-
2013.2
- Started by
- Henry Nash
- Completed by
- Henry Nash
Related branches
Related bugs
Sprints
Whiteboard
(boden) -----
A related topic that's not yet clear to me; how do the notion of service users play out in the multi-domain scheme? For example, the standard way to setup OpenStack (as per OpenStack install guide) is to create a service user for each OS service (nova, glance, etc.) and use this service user in the keystone auth section of each service's config. In a multi-domain scheme, does this service user need to be a "global admin"?
Note -- there may be an obvious solution to this question already, I just haven't had time to play with domains enough to verify. Also note -- I think it would be great if the OS install docs could be updated to call out the reccommended approach for handling service users in a multi-domain scenario.
Gerrit topic: https:/
Addressed by: https:/
Implement role assignment inheritance (OS-INHERIT extension)
Work Items
Work items:
Extend roles metadata to be a list of dicts, rather than a simple list: DONE
Extend the grant apis calls to take the 'inherited' flag: DONE
Provide a config setting to enable/display extension: DONE
Extend routers to support /OS-INHERIT/: DONE
Enhance 'get_roles_
Modify response to 'list_role_
Add SQL migration script to modify list of roles to list of dicts: DONE
Expand testing to comprehensively test inherited role assignments: DONE
Dependency tree
* Blueprints in grey have been implemented.
