Tenantless role assignments
As opposed to "global" roles (roles which are effective against all tenants), or domain-based role assignments that are inherited to projects (roles which are effective against a large group of tenants), keystone has been presented with several use cases that would be satisfied by context-free role assignments (those that do not apply at all to domains or projects), and which could be consumed by generating "unscoped" tokens.
Most OpenStack components are inherently multi-tenant, so keystone's authorization mechanism has been rigidly constructed to support the multi-tenant use case. "Global" roles have been largely rejected by the community as they present a non-explicit means of expressing authorization that generally provides more authorization than is ever actually necessary.
As an immediate use case, portions of keystone's own API are not multi-tenant in nature -- they're effectively tenantless (regardless of whether you perceive domains or projects to be the scope of a real-world "tenant"). Examples include the "create domain" operation and service catalog management.
One of keystone's longest standing bugs is about the scope of "admin"ness ( https:/
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Superseded
- Series goal:
- None
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
- Dolph Mathews
Related branches
Related bugs
Sprints
Whiteboard
(atiwari)
The biggest problem here is “role definitions are just a name and keystone can not differentiate foo(Admin) from bar(Admin)“ that is why Admin on a project become is admin on keystone resources (prject,users, group….) too.
This issue is mainly due to insufficiency of role data model which is nothing but just a name and there is no way we can define same role name for different services.
You've already proposed prefixing role names with service names -- there's no reason why you can't do that in your deployment today. -dolph
In my opinion below is the the solution for “I don't have a specific solution to advocate, but being an admin on *any* tenant simply *cannot* allow you to administer all of keystone.” issue or https:/
This blueprint represents a clean solution to that problem. -dolph
1. Keystone should register itself in keystone along with other services and has given some name unique service_id. (e.g. keystone or identity=100 , NOVA=110 and Swift=120) (chicken and egg problem but can be done through system bootstrap)
Keystone should not do *anything* automagically. Deployers are already expected to include the identity service in their service catalogs. -dolph
2. Role definition should be scoped to a service_id, so that every service can create their own role.(e.g. Admin(100), Admin(110) and Admin(120)).
This discussion is entirely out of scope for this blueprint. -dolph
3. Role definition should have some info (may be a flag like for_non_
We had the same discussion when introducing domain-based role assignments, and determined it was a terrible idea because roles are just strings and this kind of metadata is outside the scope of keystone to manage or enforce. -dolph
4. There should be validation in role assignment based on role definition’s for_non_
See #3 -dolph
5. Based on scoping (domain/project) Token response should return role list with service_id (e.g. [Admin(110), Admin(120)])
This discussion is entirely out of scope for this blueprint. -dolph
6. Service scoped Auth (token) request should also be provided.
This discussion is entirely out of scope for this blueprint. -dolph
7. For any keystone API calls, internal user credential (which is used to validate against policy) should have role with service_id (e.g. [Admin(110), Admin(120)])
Credentials are not used to validate against policy, nor should they be. -dolph
8. Keystone policy which considers role should also add “service_id” in policy (e.g. "identity:
8.1 Note: target.service_id should be always 100 because we are operating on identity API, that means the target is controlled by identity(100) service.
8.2 For identity:
This discussion is entirely out of scope for this blueprint. -dolph
I think if we really want to make keystone useful we should fix the above mentioned issues.
(gyee) is there an etherpad/
(dolph) no, it's marked as superseded and abandoned
How are projectless roles assigned? i.e.
PUT /users/
What does it look like as the result of GET /role_assignments? I presume the "scope" part will be either absent or empty.
Since user will only get these roles if the token is unscoped, is there a way to "explicitly" request an unscoped token, even in the presence of a valid default project?