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
________________________