Open Stack

The TL;DR - We ran into problems with permissions for users within the same
tenant. With the current access controls it is impossible to fix this
without isolating each user in a personal project. Can we fix the
policy.json grammar to give us the access controls we want, or am I stupid
and missing something?

We're in the midst of deploying a clean-slate build of Havana. This gives
us an opportunity to revisit some of the mistakes we made with permissions
since our Essex deployment.
With Essex, projects had between 5 and 100 people in them. Permissions for
nova, nova-volume and glance were such that any member of a project had the
same privileges on resources as every other member (non-admin).

The result was that individual users could modify and delete other users
resources. Our users are amazing and completely respected all of their
project-member's instances, images and volumes. However, on occasion one
would miss click and shutdown a server.

The quick fix was to disable deletes (and other destructive operations) to
users without a "project_admin" role.

We're still looking for the better fix. What we want: most users can create
resources and delete their own resources. A few users can delete other
peoples resources (project_admins). Resource quotas are set at the project
level.

To my knowledge, there's no way to achieve the above vision with the
current setup. policy.json files are structured to test an API action
against the user roles and the user's tenant. There is no Resource.User ==
User check.

The only option we see is to isolate each user in their own project. This
has the disadvantage that we can't enforce quotas on our "real-world
project" level since domain quotas for nova won't be here until Icehouse at
the soonest.

Are we missing something? How are other people altering policy.json files?
How are you looking at projects, users and domains?

Thanks,

~ Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20131205/bb3fbbb8/attachment.html>