Open Stack

On 06/02/2015 06:16 PM, David Lyle wrote:
> The Horizon project also uses the nova policy.json file to do role based
> access control (RBAC) on the actions a user can perform. If the defaults
> are hidden in the code, that makes those checks a lot more difficult to
> perform. Horizon will then get to duplicate all the hard coded defaults
> in our code base. Fully understanding UI is not everyone's primary
> concern, I will just point out that it's a terrible user experience to
> have 10 actions listed on an instance that will only fail when actually
> attempted by making the API call.
> 
> To accomplish this level of RBAC, Horizon has to maintain a sync'd copy
> of the nova policy file. The move to centralized policy is something I
> am very excited about. But this seems to be a move in the opposite
> direction.
> 
> I think simply documenting the default values in the policy.json file
> would be a simpler and more straight-forward approach. I think the
> defcore resolution is also a documentation issue.

I think we should separate what you want to do:

* Determine Policy User Can Do

With how you are are currently doing it:

* Reading the nova policy.json file

Because I definitely think that determining the policy the user can do
is definitely something we all want, but reading the policy.json file
only works if Horizon and the API servers are on the same nodes.
Otherwise you are copying a bunch of stuff around. It also requires
(today) a ton of the url logic in Nova to be duplicated in to Horizon
because our policy names are weird.

Documentation isn't really good enough, we'd actually like to WARN the
operator if they did a silly thing with their policy to get preventive
about configuration mistakes and errors. For that, we need a baseline.

How I'd imagine this going is the following:

Default Policy in Code => Patch Policy in policy.json on the API server
=> Dynamic Policy from Keystone

(things to the right override things to the left)

We could provide a /policy API resource for users to GET a policy
definition that's relevant to them (and something more global with admin
credentials). I would imagine this would only provide Default + Patch,
if you wanted Dynamic you'd ask Keystone for that (once it exists).

That would be a better near term fetching point from Horizon instead of
syncing a file. In the Dynamic Policy world that would be the origin
source of truth for Keystone to get started, and it could dynamically
modify after that point.

	-Sean

-- 
Sean Dague
http://dague.net