openstack team mailing list archive

[Craig Lee <lee@xxxxxxxx>]

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