Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Jamie Lennox]

On 28 June 2016 at 04:22, Jay Faulkner  wrote:

> Is this spec still alive? I'm working on the spec for Ironic integration
> of Keystone policy, and like some of the items in the draft, but obviously
> they aren't binding and I can't really reference them unless the spec
> merges or at least shows progress towards merging.
>
> Thanks,
> Jay Faulkner
> OSIC
>
> Hey Jay,

The spec is conceptually still active but we haven't made any progress
recently.

The problem that we discovered in Austin was basically that for most
operations services simply check that a user is a member of the project
they are operating on - and that is any role. Now to introduce read only
roles like observer breaks this pattern and would require openstack as a
whole to at least define a standard member role. This should be possible
but it is a much more invasive change than the spec was intended to be so
it has lost a bit of momentum.


Jamie


> On Jan 31, 2016, at 6:15 PM, Adam Young  wrote:
>
> On 01/30/2016 08:24 PM, Henry Nash wrote:
>
>
> On 30 Jan 2016, at 21:55, Adam Young < 
> ayo...@redhat.com> wrote:
>
> On 01/30/2016 04:14 PM, Henry Nash wrote:
>
> Hi Adam,
>
> Fully support this kind of approach.
>
> I am still concerned over the scope check, since we do have examples of
> when there is more than one (target) scope check, e.g.: an API that might
> operate on an object that maybe global, domain or project specific - in
> which case you need to “match up with scope checks with the object in
> question”, for example for a given API:
>
> If cloud admin, allow the API
> If domain admin and the object is domain or project specific, then allow
> the API
> If project admin and the object is project specific then allow the API
>
> Today we can (and do with keystone) encode this in policy rules. I’m not
> clear how the “scope check in code” will work in this kind of situation.
>
> I originally favored an approach that a user would need to get a token
> scoped to a resource in order to affect change on that resource, and admin
> users could get tokens scoped to anything,  but I know that makes things
> harder for Administrators trying to fix broken deployments. So I backed off
> on that approach.
>
> I think the right answer would be that the role check would set some value
> to indicate it was an admin override.  So long as the check does not need
> the actual object from the database, t can perform whatever logic we like.
>
> The policy check deep in the code can be as strict or permissive as it
> desires.  If there is a need to re-check the role for an admin check there,
> policy can still do so.  A role check that passes at the Middleware level
> can still be blocked at the in-code level.
>
> "If domain admin and the object is domain or project specific, then allow
> the API" is trh tricky one, but I don't think we even have a solution for
> that now.  Domain1->p1->p2->p3 type hierarchies don't allow operations on
> p3 with a token scoped to Domain1.
>
>
> So we do actually support things like that, e.g. (from the domain specific
> role additions):
>
> ”identity:some_api": role:admin
> and project_domain_id:%(target.role.domain_id)s(which means I’m project
> admin and the domain specific role I am going to manipulate is specific to
> my domain)
>
> ….and although we don’t have this in our standard policy, you could also
> write
>
> ”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s
>(which means I’m domain admin and I can do some operation on any project
> in my domain)
>
>
> Yeah, we do some things like this in the Keystone policy file, but not in
> remote services, yet, and it would only work for Domain of the project, not
> for any arbitrary project in the chain under Domain1:  roles on p1 or P2
> would have to be inherited in order to affect any change on resources in 3.
>
>
>
> I think that in those cases, I would still favor the user getting a token
> from Keystone scoped to p3, and use the inherited-role-assignment approach.
>
>
>
> Henry
>
> On 30 Jan 2016, at 17:44, Adam Young  wrote:
>
> I'd like to bring people's attention to a Cross Project spec that has the
> potential to really strengthen the security story for OpenStack in a
> scalable way.
>
> "A common policy scenario across all projects"
> 
> https://review.openstack.org/#/c/245629/
>
> The summary version is:
>
> Role name or patternExplanation or example
>
> -:--
> admin:  Overall cloud admin
> service  :  for service users only, not real
> humans
> {service_type}_admin :  identity_admin, compute_admin,
> network_admin etc.
> {service_type}_{api_resource}_manager: identity_user_manager,
>

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Jay Faulkner]

Is this spec still alive? I'm working on the spec for Ironic integration of 
Keystone policy, and like some of the items in the draft, but obviously they 
aren't binding and I can't really reference them unless the spec merges or at 
least shows progress towards merging.

Thanks,
Jay Faulkner
OSIC

On Jan 31, 2016, at 6:15 PM, Adam Young 
> wrote:

On 01/30/2016 08:24 PM, Henry Nash wrote:

On 30 Jan 2016, at 21:55, Adam Young 
<ayo...@redhat.com> wrote:

On 01/30/2016 04:14 PM, Henry Nash wrote:
Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples of when 
there is more than one (target) scope check, e.g.: an API that might operate on 
an object that maybe global, domain or project specific - in which case you 
need to “match up with scope checks with the object in question”, for example 
for a given API:

If cloud admin, allow the API
If domain admin and the object is domain or project specific, then allow the API
If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m not clear 
how the “scope check in code” will work in this kind of situation.
I originally favored an approach that a user would need to get a token scoped 
to a resource in order to affect change on that resource, and admin users could 
get tokens scoped to anything,  but I know that makes things harder for 
Administrators trying to fix broken deployments. So I backed off on that 
approach.

I think the right answer would be that the role check would set some value to 
indicate it was an admin override.  So long as the check does not need the 
actual object from the database, t can perform whatever logic we like.

The policy check deep in the code can be as strict or permissive as it desires. 
 If there is a need to re-check the role for an admin check there, policy can 
still do so.  A role check that passes at the Middleware level can still be 
blocked at the in-code level.

"If domain admin and the object is domain or project specific, then allow the 
API" is trh tricky one, but I don't think we even have a solution for that now. 
 Domain1->p1->p2->p3 type hierarchies don't allow operations on p3 with a token 
scoped to Domain1.

So we do actually support things like that, e.g. (from the domain specific role 
additions):

”identity:some_api": role:admin and project_domain_id:%(target.role.domain_id)s 
   (which means I’m project admin and the domain specific role I am going to 
manipulate is specific to my domain)

….and although we don’t have this in our standard policy, you could also write

”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s
(which means I’m domain admin and I can do some operation on any project in my 
domain)

Yeah, we do some things like this in the Keystone policy file, but not in 
remote services, yet, and it would only work for Domain of the project, not for 
any arbitrary project in the chain under Domain1:  roles on p1 or P2 would have 
to be inherited in order to affect any change on resources in 3.



I think that in those cases, I would still favor the user getting a token from 
Keystone scoped to p3, and use the inherited-role-assignment approach.



Henry

On 30 Jan 2016, at 17:44, Adam Young 
> wrote:

I'd like to bring people's attention to a Cross Project spec that has the 
potential to really strengthen the security story for OpenStack in a scalable 
way.

"A common policy scenario across all projects" 
 
https://review.openstack.org/#/c/245629/

The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not real humans
{service_type}_admin :  identity_admin, compute_admin, 
network_admin etc.
{service_type}_{api_resource}_manager: identity_user_manager,
   compute_server_manager, 
network_subnet_manager
observer :  read only access
{service_type}_observer  : identity_observer, image_observer


Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph 
Matthews just took it to the next level.  It is worth a read.

I think this is the way to go.  There might be details on how to get there, but 
the granularity is about right.
If we go with that approach, we might want to rethink about how we enforce 
policy.  Specifically, I think we should split the policy enforcement up into 
two stages:

1.  Role check.  This only needs to know the service and the api resource.  As 
such, it could happen in 

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Adam Young]

On 01/30/2016 08:24 PM, Henry Nash wrote:


On 30 Jan 2016, at 21:55, Adam Young > wrote:


On 01/30/2016 04:14 PM, Henry Nash wrote:

Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples 
of when there is more than one (target) scope check, e.g.: an API 
that might operate on an object that maybe global, domain or project 
specific - in which case you need to “match up with scope checks 
with the object in question”, for example for a given API:


If cloud admin, allow the API
If domain admin and the object is domain or project specific, then 
allow the API

If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m 
not clear how the “scope check in code” will work in this kind of 
situation.
I originally favored an approach that a user would need to get a 
token scoped to a resource in order to affect change on that 
resource, and admin users could get tokens scoped to anything,  but I 
know that makes things harder for Administrators trying to fix broken 
deployments. So I backed off on that approach.


I think the right answer would be that the role check would set some 
value to indicate it was an admin override.  So long as the check 
does not need the actual object from the database, t can perform 
whatever logic we like.


The policy check deep in the code can be as strict or permissive as 
it desires.  If there is a need to re-check the role for an admin 
check there, policy can still do so.  A role check that passes at the 
Middleware level can still be blocked at the in-code level.


"If domain admin and the object is domain or project specific, then 
allow the API" is trh tricky one, but I don't think we even have a 
solution for that now.  Domain1->p1->p2->p3 type hierarchies don't 
allow operations on p3 with a token scoped to Domain1.


So we do actually support things like that, e.g. (from the domain 
specific role additions):


”identity:some_api": role:admin 
and project_domain_id:%(target.role.domain_id)s(which means I’m 
project admin and the domain specific role I am going to manipulate is 
specific to my domain)


….and although we don’t have this in our standard policy, you could 
also write


”identity:some_api": role:admin and 
domain_id:%(target.project.domain_id)s(which means I’m domain 
admin and I can do some operation on any project in my domain)


Yeah, we do some things like this in the Keystone policy file, but not 
in remote services, yet, and it would only work for Domain of the 
project, not for any arbitrary project in the chain under Domain1:  
roles on p1 or P2 would have to be inherited in order to affect any 
change on resources in 3.






I think that in those cases, I would still favor the user getting a 
token from Keystone scoped to p3, and use the 
inherited-role-assignment approach.





Henry

On 30 Jan 2016, at 17:44, Adam Young > wrote:


I'd like to bring people's attention to a Cross Project spec that 
has the potential to really strengthen the security story for 
OpenStack in a scalable way.


"A common policy scenario across all projects" 
https://review.openstack.org/#/c/245629/


The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not 
real humans
{service_type}_admin :  identity_admin, 
compute_admin, network_admin etc.

{service_type}_{api_resource}_manager: identity_user_manager,
   compute_server_manager, 
network_subnet_manager

observer :  read only access
{service_type}_observer  : identity_observer, 
image_observer



Jamie Lennox originally wrote the spec that got the ball rolling, 
and Dolph Matthews just took it to the next level.  It is worth a read.


I think this is the way to go.  There might be details on how to 
get there, but the granularity is about right.
If we go with that approach, we might want to rethink about how we 
enforce policy.  Specifically, I think we should split the policy 
enforcement up into two stages:


1.  Role check.  This only needs to know the service and the api 
resource.  As such, it could happen in middleware.


2. Scope check:  for user or project ownership.  This happens in 
the code where it is currently called.  Often, an object needs to 
be fetched from the database


The scope check is an engineering decision:  Nova developers need 
to be able to say where to find the scope on the virtual machine, 
Cinder developers on the volume objects.


Ideally, The python-*clients, Horizon and other tools would be able 
to determine 

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Henry Nash]

Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples of when 
there is more than one (target) scope check, e.g.: an API that might operate on 
an object that maybe global, domain or project specific - in which case you 
need to “match up with scope checks with the object in question”, for example 
for a given API:

If cloud admin, allow the API
If domain admin and the object is domain or project specific, then allow the API
If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m not clear 
how the “scope check in code” will work in this kind of situation.

Henry

> On 30 Jan 2016, at 17:44, Adam Young  wrote:
> 
> I'd like to bring people's attention to a Cross Project spec that has the 
> potential to really strengthen the security story for OpenStack in a scalable 
> way.
> 
> "A common policy scenario across all projects" 
> https://review.openstack.org/#/c/245629/
> 
> The summary version is:
> 
> Role name or patternExplanation or example
> -:--
> admin:  Overall cloud admin
> service  :  for service users only, not real 
> humans
> {service_type}_admin :  identity_admin, compute_admin, 
> network_admin etc.
> {service_type}_{api_resource}_manager: identity_user_manager,
>compute_server_manager, 
> network_subnet_manager
> observer :  read only access
> {service_type}_observer  : identity_observer, image_observer
> 
> 
> Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph 
> Matthews just took it to the next level.  It is worth a read.
> 
> I think this is the way to go.  There might be details on how to get there, 
> but the granularity is about right.
> If we go with that approach, we might want to rethink about how we enforce 
> policy.  Specifically, I think we should split the policy enforcement up into 
> two stages:
> 
> 1.  Role check.  This only needs to know the service and the api resource.  
> As such, it could happen in middleware.
> 
> 2. Scope check:  for user or project ownership.  This happens in the code 
> where it is currently called.  Often, an object needs to be fetched from the 
> database
> 
> The scope check is an engineering decision:  Nova developers need to be able 
> to say where to find the scope on the virtual machine, Cinder developers on 
> the volume objects.
> 
> Ideally, The python-*clients, Horizon and other tools would be able to 
> determine what capabilities a given token would provide based on the roles 
> included in the validation response. If the role check is based on the URL as 
> opposed to the current keys in the policy file, the client can determine 
> based on the request and the policy file whether the user would have any 
> chance of succeeding in a call. As an example, to create a user in Keystone, 
> the API is:
> 
> POST https://hostname:port/v3/users
> 
> Assuming the client has access to the appropriate policy file, if can 
> determine that a token with only the role "identity_observer" would not have 
> the ability to execute that command.  Horizon could then modify the users 
> view to remove the "add user" form.
> 
> For user management, we want to make role assignments as simple as possible 
> and no simpler.  An admin should not have to assign all of the individual 
> roles that a user needs.  Instead, assigning the role "Member" should imply 
> all of the subordinate roles that a user needs to perform the standard 
> workflows.  Expanding out the implied roles can be done either when issuing a 
> token, or when evaluating the policy file, or both.
> 
> I'd like to get the conversation on this started here on the mailing list, 
> and lead in to a really productive set of talks at the Austin summit.
> 
> 
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Adam Young]

On 01/30/2016 04:14 PM, Henry Nash wrote:

Hi Adam,

Fully support this kind of approach.

I am still concerned over the scope check, since we do have examples of when 
there is more than one (target) scope check, e.g.: an API that might operate on 
an object that maybe global, domain or project specific - in which case you 
need to “match up with scope checks with the object in question”, for example 
for a given API:

If cloud admin, allow the API
If domain admin and the object is domain or project specific, then allow the API
If project admin and the object is project specific then allow the API

Today we can (and do with keystone) encode this in policy rules. I’m not clear 
how the “scope check in code” will work in this kind of situation.
I originally favored an approach that a user would need to get a token 
scoped to a resource in order to affect change on that resource, and 
admin users could get tokens scoped to anything,  but I know that makes 
things harder for Administrators trying to fix broken deployments. So I 
backed off on that approach.


I think the right answer would be that the role check would set some 
value to indicate it was an admin override.  So long as the check does 
not need the actual object from the database, t can perform whatever 
logic we like.


The policy check deep in the code can be as strict or permissive as it 
desires.  If there is a need to re-check the role for an admin check 
there, policy can still do so.  A role check that passes at the 
Middleware level can still be blocked at the in-code level.


"If domain admin and the object is domain or project specific, then 
allow the API" is trh tricky one, but I don't think we even have a 
solution for that now.  Domain1->p1->p2->p3 type hierarchies don't allow 
operations on p3 with a token scoped to Domain1.


I think that in those cases, I would still favor the user getting a 
token from Keystone scoped to p3, and use the inherited-role-assignment 
approach.





Henry


On 30 Jan 2016, at 17:44, Adam Young  wrote:

I'd like to bring people's attention to a Cross Project spec that has the 
potential to really strengthen the security story for OpenStack in a scalable 
way.

"A common policy scenario across all projects" 
https://review.openstack.org/#/c/245629/

The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not real humans
{service_type}_admin :  identity_admin, compute_admin, 
network_admin etc.
{service_type}_{api_resource}_manager: identity_user_manager,
compute_server_manager, 
network_subnet_manager
observer :  read only access
{service_type}_observer  : identity_observer, image_observer


Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph 
Matthews just took it to the next level.  It is worth a read.

I think this is the way to go.  There might be details on how to get there, but 
the granularity is about right.
If we go with that approach, we might want to rethink about how we enforce 
policy.  Specifically, I think we should split the policy enforcement up into 
two stages:

1.  Role check.  This only needs to know the service and the api resource.  As 
such, it could happen in middleware.

2. Scope check:  for user or project ownership.  This happens in the code where 
it is currently called.  Often, an object needs to be fetched from the database

The scope check is an engineering decision:  Nova developers need to be able to 
say where to find the scope on the virtual machine, Cinder developers on the 
volume objects.

Ideally, The python-*clients, Horizon and other tools would be able to 
determine what capabilities a given token would provide based on the roles 
included in the validation response. If the role check is based on the URL as 
opposed to the current keys in the policy file, the client can determine based 
on the request and the policy file whether the user would have any chance of 
succeeding in a call. As an example, to create a user in Keystone, the API is:

POST https://hostname:port/v3/users

Assuming the client has access to the appropriate policy file, if can determine that a token with 
only the role "identity_observer" would not have the ability to execute that command.  
Horizon could then modify the users view to remove the "add user" form.

For user management, we want to make role assignments as simple as possible and no 
simpler.  An admin should not have to assign all of the individual roles that a user 
needs.  Instead, assigning the role "Member" should imply all of the 
subordinate roles that a user needs to perform the standard workflows.  Expanding out the 
implied roles can be 

[openstack-dev] [keystone][cross-project] Standardized role names and policy

[Adam Young]

I'd like to bring people's attention to a Cross Project spec that has 
the potential to really strengthen the security story for OpenStack in a 
scalable way.


"A common policy scenario across all projects" 
https://review.openstack.org/#/c/245629/


The summary version is:

Role name or patternExplanation or example
-:--
admin:  Overall cloud admin
service  :  for service users only, not real 
humans
{service_type}_admin :  identity_admin, compute_admin, 
network_admin etc.

{service_type}_{api_resource}_manager: identity_user_manager,
compute_server_manager, 
network_subnet_manager

observer :  read only access
{service_type}_observer  : identity_observer, image_observer


Jamie Lennox originally wrote the spec that got the ball rolling, and 
Dolph Matthews just took it to the next level.  It is worth a read.


I think this is the way to go.  There might be details on how to get 
there, but the granularity is about right.
If we go with that approach, we might want to rethink about how we 
enforce policy.  Specifically, I think we should split the policy 
enforcement up into two stages:


1.  Role check.  This only needs to know the service and the api 
resource.  As such, it could happen in middleware.


2. Scope check:  for user or project ownership.  This happens in the 
code where it is currently called.  Often, an object needs to be fetched 
from the database


The scope check is an engineering decision:  Nova developers need to be 
able to say where to find the scope on the virtual machine, Cinder 
developers on the volume objects.


Ideally, The python-*clients, Horizon and other tools would be able to 
determine what capabilities a given token would provide based on the 
roles included in the validation response. If the role check is based on 
the URL as opposed to the current keys in the policy file, the client 
can determine based on the request and the policy file whether the user 
would have any chance of succeeding in a call. As an example, to create 
a user in Keystone, the API is:


POST https://hostname:port/v3/users

Assuming the client has access to the appropriate policy file, if can 
determine that a token with only the role "identity_observer" would not 
have the ability to execute that command.  Horizon could then modify the 
users view to remove the "add user" form.


For user management, we want to make role assignments as simple as 
possible and no simpler.  An admin should not have to assign all of the 
individual roles that a user needs.  Instead, assigning the role 
"Member" should imply all of the subordinate roles that a user needs to 
perform the standard workflows.  Expanding out the implied roles can be 
done either when issuing a token, or when evaluating the policy file, or 
both.


I'd like to get the conversation on this started here on the mailing 
list, and lead in to a really productive set of talks at the Austin summit.




__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [keystone][cross-project] Standardized role names and policy

[Henry Nash]

> On 30 Jan 2016, at 21:55, Adam Young  > wrote:
> 
> On 01/30/2016 04:14 PM, Henry Nash wrote:
>> Hi Adam,
>> 
>> Fully support this kind of approach.
>> 
>> I am still concerned over the scope check, since we do have examples of when 
>> there is more than one (target) scope check, e.g.: an API that might operate 
>> on an object that maybe global, domain or project specific - in which case 
>> you need to “match up with scope checks with the object in question”, for 
>> example for a given API:
>> 
>> If cloud admin, allow the API
>> If domain admin and the object is domain or project specific, then allow the 
>> API
>> If project admin and the object is project specific then allow the API
>> 
>> Today we can (and do with keystone) encode this in policy rules. I’m not 
>> clear how the “scope check in code” will work in this kind of situation.
> I originally favored an approach that a user would need to get a token scoped 
> to a resource in order to affect change on that resource, and admin users 
> could get tokens scoped to anything,  but I know that makes things harder for 
> Administrators trying to fix broken deployments. So I backed off on that 
> approach.
> 
> I think the right answer would be that the role check would set some value to 
> indicate it was an admin override.  So long as the check does not need the 
> actual object from the database, t can perform whatever logic we like.
> 
> The policy check deep in the code can be as strict or permissive as it 
> desires.  If there is a need to re-check the role for an admin check there, 
> policy can still do so.  A role check that passes at the Middleware level can 
> still be blocked at the in-code level.
> 
> "If domain admin and the object is domain or project specific, then allow the 
> API" is trh tricky one, but I don't think we even have a solution for that 
> now.  Domain1->p1->p2->p3 type hierarchies don't allow operations on p3 with 
> a token scoped to Domain1.

So we do actually support things like that, e.g. (from the domain specific role 
additions):

”identity:some_api": role:admin and project_domain_id:%(target.role.domain_id)s 
   (which means I’m project admin and the domain specific role I am going to 
manipulate is specific to my domain)

….and although we don’t have this in our standard policy, you could also write

”identity:some_api": role:admin and domain_id:%(target.project.domain_id)s
(which means I’m domain admin and I can do some operation on any project in my 
domain)

> 
> I think that in those cases, I would still favor the user getting a token 
> from Keystone scoped to p3, and use the inherited-role-assignment approach.
> 
> 
>> 
>> Henry
>> 
>>> On 30 Jan 2016, at 17:44, Adam Young >> > wrote:
>>> 
>>> I'd like to bring people's attention to a Cross Project spec that has the 
>>> potential to really strengthen the security story for OpenStack in a 
>>> scalable way.
>>> 
>>> "A common policy scenario across all projects" 
>>> https://review.openstack.org/#/c/245629/ 
>>> 
>>> 
>>> The summary version is:
>>> 
>>> Role name or patternExplanation or example
>>> -:--
>>> admin:  Overall cloud admin
>>> service  :  for service users only, not real 
>>> humans
>>> {service_type}_admin :  identity_admin, compute_admin, 
>>> network_admin etc.
>>> {service_type}_{api_resource}_manager: identity_user_manager,
>>>compute_server_manager, 
>>> network_subnet_manager
>>> observer :  read only access
>>> {service_type}_observer  : identity_observer, image_observer
>>> 
>>> 
>>> Jamie Lennox originally wrote the spec that got the ball rolling, and Dolph 
>>> Matthews just took it to the next level.  It is worth a read.
>>> 
>>> I think this is the way to go.  There might be details on how to get there, 
>>> but the granularity is about right.
>>> If we go with that approach, we might want to rethink about how we enforce 
>>> policy.  Specifically, I think we should split the policy enforcement up 
>>> into two stages:
>>> 
>>> 1.  Role check.  This only needs to know the service and the api resource.  
>>> As such, it could happen in middleware.
>>> 
>>> 2. Scope check:  for user or project ownership.  This happens in the code 
>>> where it is currently called.  Often, an object needs to be fetched from 
>>> the database
>>> 
>>> The scope check is an engineering decision:  Nova developers need to be 
>>> able to say where to find the scope on the virtual machine, Cinder 
>>> developers on the volume objects.
>>> 
>>> Ideally, The python-*clients, Horizon and other tools would be able to 
>>> determine what capabilities a given