openstack team mailing list archive

[Joe Savak <joe.savak@xxxxxxxxxxxxx>]

Hi Jay,

      See my comments below & thanks for the feedback. :)



What is the difference between a resource group and a group?



A group in keystone is a collection of users. This aids in role assignments and makes a logical collection of users possible.

A resource group in the context of keystone is an identifier of a distributed restriction that can be assigned to policies and users.



For example: Policy "x" defines that user "joe" can perform the capability "deleteServers". That policy is tied to a resource group called "prod-servers".

Hitting up nova in a GET /resource-group/prod-servers will yield all the resources (with respect to that service) that comprise that resource group. Those are the servers that joe may delete.



Do your scalability concerns revolve around having a single policy BLOB for the service and the corresponding single record, multi-writer data access pattern that would mean? If you had a policy BLOB per group, would that assuage those concerns? Meaning... a compromise between having a REST API that would essentially operate on single resources and the existing API that changes all policies in one call?



The proposed solution above helps distribute the real load of a fine-grained access control solution out to the services that would know more about the resources.



Thanks,

joe



-----Original Message-----
From: openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+joe.savak=rackspace.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Jay Pipes
Sent: Tuesday, April 02, 2013 9:58 AM
To: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Keystone Design Session - Fine Grained Access Control



On 04/02/2013 09:51 AM, Joe Savak wrote:

> I'd like to propose a design session on Fine Grained Access Control

> for the summit.

>

> Session info: http://summit.openstack.org/cfp/edit/99

>

> Blueprint:

> https://blueprints.launchpad.net/keystone/+spec/fine-grain

>

> Details:

>

> a large implementation, there can be many users each having some level

> of access to a shared pool of resources. Not all users need that much

> access though and there are cases where access must be restricted

> further. V3 introduces policies and that works for restricting access

> to certain capabilities (only a user with the role "admin" or group

> "foo" can create server in nova, etc). Policies bloat up though if

> they need to get down the resource level (only joe can delete server

> "ABC").



Once you go down this super-fine-grained route and start managing privileges in this manner, it definitely complicates things. :)



> This blue print (which will be expanded upon) introduces the concept

> of a "resource group" in an attempt to provide highly-available,

> easily modifiable fine grained access control to OpenStack services.



What is the difference between a resource group and a group?



> 1. The v3 core spec doesn't allow for fine-grained access control.

> You can force it into policy blobs, but that isn't scalable or

> transparent enough



Do your scalability concerns revolve around having a single policy BLOB for the service and the corresponding single record, multi-writer data access pattern that would mean? If you had a policy BLOB per group, would that assuage those concerns? Meaning... a compromise between having a REST API that would essentially operate on single resources and the existing API that changes all policies in one call?



Best,

-jay



_______________________________________________

Mailing list: https://launchpad.net/~openstack

Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>

Unsubscribe : https://launchpad.net/~openstack

More help   : https://help.launchpad.net/ListHelp