Tenantless role assignments

Registered by Dolph Mathews

This blueprint has been superseded. See the newer blueprint "Service-scoped tokens and role assignments" for updated plans.

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://bugs.launchpad.net/keystone/+bug/968696 ), which is treated as global authorization even though the intended use case is actually tenantless (and it happens to be abused for the purpose of cross-tenant / multi-tenant authorization).

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
Completed by
Dolph Mathews

Related branches

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://bugs.launchpad.net/keystone/+bug/968696

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_project_use_only=true) to guide role assignment logic, so that certain role can/can’t be assigned to a project. (e.g. Admin(100,true), Admin(110,false) and Admin(120,false))

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_project_use_only filed, so that non_project roles can’t be assigned to a project.

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:create_project": ["role:Admin and service_id:%(100)s"])
  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:create_project API call if user have “Admin(110)” (admin role scoped to a project) wd not satisfy "role:Admin and service_id:%(100)s" policy

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/gist/proposed spec on this? I want to get an idea on the API impacts.
(dolph) no, it's marked as superseded and abandoned

How are projectless roles assigned? i.e.

PUT /users/{user_id}/roles/{role_id}

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?

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.