Open Stack

On Oct 10, 2012, at 8:59 AM, Mark McLoughlin <markmc at redhat.com> wrote:

> 
> But I think the specific example we're talking about here is pretty
> dumb. Having a 'projectadmin' role which applies to all projects you're
> a member doesn't seem very useful. We really need users to have
> per-project roles, and that concept would need to be added in keystone.

Just a note. There are currently no global roles in keystone. So this is already
a specific per-project role.
> 
> I'm leaning towards dropping this feature for now until we have a really
> compelling use case for it. Now that I understand the context a bit
> better, I think I'd be against adding this "global projectadmin role"
> idea at all.

> 
> The danger with leaving it in even if there's no good use case for it is
> that folks might find bad/confusing use cases for it :)


I agree that this particular feature needs a compelling use case. Its too bad
because the feature itself is cool I think it will just lead to bad decisions
in the fulture.

To totally hijack the thread: I think the best thing we could do with policy
is to start looking at it from an operator perspective. The plethora of options
in the current policy.json is confusing at best.

What we really need is some effort given to coming up with policy.json best
practices:

a) making sure the policies are named in a consistent manner
b) grouping the policies in a way that makes them easy to edit for operators.
In other words, I think in most cases there are only a few policies that will be
touched, so make configuring those easy
c) standard definitions of which things should be policy controlled and ensuring
that all of those are in place.
d) documentation on configuring policies

In addition, I see the following future-thinking possibilities that are all directly
related to how we integrate policies with keystone:

a) Global (user-centric roles). Ryan Lane sent a great email about why these are
really important for administrators
b) Centrally controlled policy (i.e. store it in keystone vs a bunch of separate files
c) Delegation of rights (i.e. Giving another user a subset of rights. This is
already being discussed in another thread.)
d) Programmable policy (we may get enough with rights delegation or user based
quotas, but the basic use case we'd like to support is that a project owner could limit
the actions of other project users. i.e. user a can launch new instances but user b
cannot.)

Vish