Cloned from launchpad blueprint https://blueprints.launchpad.net/keystone/+spec/service-scoped-role-definition.

Description:

Introduction:
========

In a large scale cloud establishments, different services (Nova, Swift, Cinder, Keystone etc…..) are managed by separate teams, these teams may operates from different geography and time zones (Let's call them “service deployers” or “service teams”). These teams don't want to depend on another team (Keystone Admin) to manage their service life cycle (e.g. The service deployer of NOVA don’t want to depend on  Keystone Admin to manage their service specific entities). Through this BP we want to resolve one of the bottleneck experienced by these teams while managing their service life cycle.

In the current Keystone model,  a service typically have two entities created in keystone to become a cloud service, those are “service definition” and endpoint(s). Let's call them "service artifacts"

Service definition: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#services-v3services

Endpoint: https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#endpoints-v3endpoints

Following are some of service life cycle events which are triggered by business requirements and need updates/addition on these service artifacts

1.    Rename service (e.g. Nova to VMS).
2.    Move a service endpoint to public from internal.
3.    Disable a service endpoint from particular region for maintenance purpose.
4.    Add another region by adding new endpoint.

These service artifacts (Service and/or Endpoint(s)) are bound to a service_id, changes made on one service artifact(s) would not affect another service.  Right now a change/addition required on service artifacts need a Keystone Admin to step in and make those changes on behalf of service deployer. This is not a desirable model to run a large scale cloud system and creates bottleneck on Keystone Admin. Ideally a service deployers should be allowed to manage life cycle of a particular service through designated Keystone REST APIs.

Problem:
=====
In the current "OpenStack Identity V3" specification Roles (Role Definition) are global entities and shared among all services on cloud infrastructure. A change in Role would screwup smooth functioning of another service. This approach of managing roles is not sufficient to handle some of use case which is extremely required for a large scale cloud establishment and also creates  bottleneck on keystone Admin. Example below

1. A service deployer (e.g. NOVA) wants to have a new role setup in keystone for their purpose only.

2. A service deployer want to rename an existing role (e.g. Admin to VM-Admin) and want to reconcile role assignments exists with old role.

3. A service deployer want to hide (disable) a role for further role assignments from particular region. (Not the scope of this BP)

4. A service deployer want to reserve a role for service admins and never what it to be used by service end users. (Not the scope of this BP)

5. Cloud provider want to make all individual service deployers self sufficient,  so that they can manage their service artifacts (Service, Endpoints, including Roles) without depending on Keystone.

6. Not friendly for tools (e.g. OpenStack Horizon or any custom tool) who want to filter out the role definitions based on service, this limitation may cause confusion for the admins while doing the role assignment. (e.g. Foo role which  is good for FooSvc will be visible for role assignment on Bar service).

7. There is no way a middle-ware can filter out unwanted role from the validate token response, which can cause https://bugs.launchpad.net/keystone/+bug/890411.

8. There is no way a use can request service scoped token. (get token scoped to project "xyx" for nova service)

9. Dependency on Keystone Admin for managing service life cycle is not scalable as well as not an agile process.

10. A cloud provider may have to support service (PaaS/SaaS) which are not an OpenStack services but follows RBAC model for Authz. These service wants to have roles created in Keystone and they want to manage the roles entity without depending on Keystone Admin.

Solution:
=====

ayoung:  long discussion about this at the summit.  The solution below is the right general approach, with the following caveats:
1.  Services and Endpoints are only two possible ways to scope a role.  There very well may be others in the future.
2.  Even though a role may defined in the context of a service, there is nothing that should limit assigning that role only within the context of the service.


Service and Endpoint data model are scoped to an id (service_id), which represents a service in cloud infrastructure.  Entities created with these data models are scoped to a particular service and  created only when a new service what to on-board over/under the cloud. An update made on these entities for a particular service should not affect another service state or smooth functioning of other service.

Role (or Role definition): https://github.com/openstack/identity-api/blob/master/openstack-identity-api/v3/src/markdown/identity-api-v3.md#roles-v3roles

All the above mentioned problem can be resolved by namescaping scoping roles (role definition).  Since the problem of namespacing is open ended, it makes sense to allow nesting of namespaces.  Instead of inveting a new abstraction to cover the namespaceing of roles, we will instead allow one role to be nested inside another role.  Thus, if one role is named "keystone"  and it has nested inside a role name "manager"  the effective role would be the  "keystone","manager"  or, potentially, "keystone:manager"

The ability to define new roles is itself an RBAC protected resource.  Role Definitions will be managed resources, and contained within projects.  Thus, it may be that the default set of roles stays Managed by users with the role "admin" in the the default domain, but a project named "keystone"  would also containt the role "keystone"  and a user with the role "admin" on the Keystone proejct would be able to create new subroles roles under the role "keystone."

**Scoping roles to a service does not mean a roles name (e.g. Admin) cannot be global or can not be used by another service. Multiple services can use same role name by creating a roles entity with same name scoped to that service.**

This way we can envision a real "Service Deployer" user (an identity in Keystone) scoped to a particular service and manages service life cycle for a service without depending on Keystone Admin.

Note: Imagine a "Service Deployer" is special user account created in Keystone administrative domain with certain privilege so that he/she can manage only a specified service. Keystone has to control the access on these entities, so that deployer of one service can not mess-up with another service artifacts. (How? need some enhancement )

Benefit:
====
1. All the required entities Service, Endpoint(s) and Role(s) are bound to a service_id and logically scoped to a service.

2. This way a service deployer can manage the service life cycle without depending on keystone Admin.

3. No data migration needed to handle problem #2

4. Keystone can create a role (e.g. svc-deployer scoped to services) and fine grained RBAC policy can be defined around the service_id to protect Foo-service from accidental update from deployer of Bar-service (or any malicious user). (e.g. role=svc-deployer and service_id=foo-svcId)

5. Apart from other problems, service deployer will achieve autonomy and don’t have to deal with keystone bottleneck issues.

6. Possible to have project and service scoped token.

Specification URL (additional information):

https://etherpad.openstack.org/p/service-scoped-role-definition