← Back to team overview

openstack team mailing list archive

Re: Keystone Design Session - Fine Grained Access Control

 

Joe, et al.,

I have been working on support for virtual organizations (VOs) in
Keystone with a focus on managing access to Swift containers across
administrative domains.  The issue of data access granularity is one
of the topics we have not addressed yet, but this seems to compliment
the notion of fine-grain control for compute resources.

I have to think that many application domains would want to have finer
grain data access control than the container level.  Obviously there
is a trade-off between access granularity and overhead, but each
application could decide how much overhead they're willing to suffer
to get the granularity of control they feel is necessary.  The
question, though, is where and how to implement the Policy Enforcement
Point(s) that enables such control, and how to integrate it with
Keystone.

How exactly is a resource group different than a group?  Is it
intended to make it easier to manage and enforce fine-grained policy?

This may be a digression, but VOs seem like an instance of a resource
group.  A user is granted access to containers across different sites
based on their VO membership.  Hence, a VO is essentially a "virtual
project" that defines a group of resources (in this case, containers).

--Craig

On 4/2/13 7:57 AM, Jay Pipes wrote:
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
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp



References