Looks like this has grown into a full discussion. Opening up to the dev
mailing list.
On 09/16/2013 10:43 AM, Lyle, David (Cloud Services) wrote:
I did run into a couple of fundamental limitations with the policy API as
implemented in Keystone.
1) policy_list and policy_get are admin_required by default in the policy
file. Obviously this can be changed in the policy file itself, but this is a
bad default. A regular user is most in need of policy rule enforcement so the
existing default does not make sense from a UI perspective.
Hmmm, this sounds like a mismatch of expectations. I would think that
the Horizon server would fetch the policy as an admin user, not the end
user, and use that to tailor their UX. It would only be a problem if
that tailoring was done on the Client side in Javascript. Why would it
matter what access control for the policy was? Why would the end user
be requesting the policy?
2) The 3 param/return fields supported by the policy API are: blob, id, type (mime-type). When
trying to utilize multiple policy files (blobs) from several services we need a way to map the blob
to a service type to know which rule set to apply. I had considered lumping all the policy blobs
into one, but there is no requirement that each policy rule will begin with e.g.,
"identity:" and several blobs could implement a rule "default" which could be
specified differently. So, I believe a service_type parameter is necessary. Additionally, is
there anything barring nova from uploading multiple policy blobs (perhaps different), each getting
unique IDs, and then having several varying compute policy blobs to choose from? Which one wins?
I haven't looked deeply at the policy API until now: It looks broken.
I would not be able to tell just from reading the code how to map a
policy file to the service that needed it. I would think that, upon
service startup, it would request the policy file that mapped to it,
either by endpoint with a fallback to a pre-service call.
I would think that you would make a tree out of the rules. At the root
would be policy. Underneath that would be the service, (then the
endpoint in the future when we support multiple per service) and then
the rules underneath those. The rules would be a json dumps of the blob
get from the policy_api.
Having devstack load the policy files into keystone would help, but 1 and 2
need to be addressed before those files are usable in Horizon.
Thanks,
David
-----Original Message-----
From: Adam Young [mailto:[email protected]]
Sent: Monday, September 16, 2013 8:16 AM
To: Julie Pichon
Cc: Matthias Runge; Gabriel Hurley; Lyle, David (Cloud Services)
Subject: Re: WebUI and user roles
On 09/16/2013 07:33 AM, Julie Pichon wrote:
"Adam Young" <[email protected]> wrote:
Gabriel and I talked at the last summit about how Horizon could
figure out what to show the user based on the roles that the user
had. At the time, I was thinking it wasn't something we could figure out at
run time.
I was wrong.
The answer is plain. We have the policy files in Keystone already,
we just don't parse them. Horizon has all the information it needs
to figure out "based on a token, what can this user do?"
I'm not certain how to make use of this, yet, but the kernel of the
idea is there.
Thanks Adam. David Lyle implemented RBAC functionality based on policy
files in Havana [0]. I think one of the problems he found was that
although policy files are in use, most services currently do not
upload them to Keystone so they are not yet queryable (?).
That is true, but it is a deployment issue that is easily solvable. We can have
devstack, packstack, and whatever else, upload the policy files at the start.
They are all in the various deployments, so it is really a trivial step to load
them into Keystone.
Regards,
Julie
[0] https://blueprints.launchpad.net/horizon/+spec/rbac
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
