openstack team mailing list archive

[Jay Pipes <jaypipes@xxxxxxxxx>]

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