Open Stack

I think the best solution is to have a clearly defined API between the
Policy Enforcement Point (the service such glance) and the policy
decision point (keystone code) that allows the full set of user
attributes and roles to be input to the PDP. Keystone will provide a
basic PDP and policy syntax, but others can enhance the policy syntax
and/or PDP code as extensions to provide the additional features that
they want. When a particular set of enhancements gets broad support then
that extension can become the new basic Keystone implementation. In this
way you would get a natural evolution of the policy to suit the
majority, with different extensions to suit the various minorities.

regards

david

On 06/12/2013 01:03, Scott Devoid wrote:
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>