Open Stack

I know I'm just making the problem more difficult, but I want to see how
policy persistence proposals fit into the future of policy, as it expands
to include policies about finer-grained entities than whole service_types.

I think the real motivator for me are use cases like Image Sharing. Glance
currently has support for sharing an image with another user--you just add
the other user's tenant id as a "member" on the image. This approach has
advantages and disadvantages
+ simple and covers 80% of use cases for sharing in some form or another
+ its fast, because I can do authorization efficiently by joining the
Images table with the Image Members table
- No good way to verify the member tenant id is valid
- No good way to be notified when the member tenant is removed
- Can't specify permission in terms of a specific user, or a role
- Can't specify permission on all / a group of images, have to do it
individually

But when I look at AWS IAM policy, for say, S3, I see an incredibly rich
policy specification. A quick googling did not turn up any articles
documenting performance hits that result from applying policies to buckets.
Furthermore, it seems like policies get applied pretty quickly without
delays or inconsistency*.

The holy grail for me would be for us to come up with a policy approach
that retains the performance, efficiency, and consistency of storing
policies virtually alongside the data the policy effects, but also provides
a central place to list and create policies, with appropriate validation of
entities like user_ids, tenants, and roles.

I'm not trying to say we should only move forward if we can get the holy
grail in Havana. But I would love to see proposals that take into
consideration their effects on consistency, efficiency, and performance,
and acknowledge that policy and fine-grained authz/access-control are
pretty much the same problem, even if they ultimately require different
solutions.

* I'm trying to practice some well-informed speculation here. Please
correct me with anecdotes or hard data!


On Fri, May 3, 2013 at 9:31 AM, Dolph Mathews <dolph.mathews at gmail.com>wrote:

> Yes, the API handles serialized policy blobs, so you could use XACML or
> anything else just as easily.
>
> -Dolph
>
>
> On Fri, May 3, 2013 at 10:14 AM, Kevin L. Mitchell <
> kevin.mitchell at rackspace.com> wrote:
>
>> On Fri, 2013-05-03 at 09:20 -0500, Dolph Mathews wrote:
>> > This API was implemented in keystone in grizzly for centralized policy
>> > storage:
>> >
>> >
>> >
>> https://github.com/openstack/identity-api/blob/master/openstack-identity-api/src/markdown/identity-api-v3.md#create-policy-post-policies
>>
>> Does this support the language-based policies now implemented in
>> oslo-incubator and used by nova, quantum, and glance?
>> --
>> Kevin L. Mitchell <kevin.mitchell at rackspace.com>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130503/9a75fc7e/attachment.html>