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 : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
