On 2/20/19 2:13 AM, melanie witt wrote:
On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann mriedemos@gmail.com wrote:
On 2/18/2019 8:22 PM, melanie witt wrote:
Right, that is the proposal in this email. That we should remove project_only=True and let the API policy check handle whether or not the user from a different project is allowed to get the instance. Otherwise, users are not able to use policy to control the behavior because it is hard-coded in the database layer.
I think this has always been the long-term goal and I remember a spec from John about it [1] but having said that, the spec was fairly complicated (to me at least) and sounds like there would be a fair bit of auditing of the API code we'd need to do before we can remove the DB API check, which means it's likely not something we can complete at this point in Stein.
For example, I think we have a lot of APIs that run the policy check on the context (project_id and user_id) as the target before even pulling the resource from the database, and the resource itself should be the target, right?
Thanks for the link -- I hadn't seen this spec yet.
Yes, Alex just pinged me in #openstack-nova and now I finally understand his point that I kept missing before. He tried a test with my WIP patch and a user from project A was able to 'nova show' an instance from project B, even though the policy was set to 'rule:admin_or_owner'. The reason is because when the instance project/user isn't passed as a target to the policy check, the policy check for the request context project_id won't do anything. There's nothing for it to compare project_id with. This is interesting because it makes me wonder, what does a policy check like that [2] do then? It will take more learning on my part about the policy system to understand it.
Sending a follow up here since Melanie and I ended up going through scope types extensively last week in IRC [0].
Long story short, keystone doesn't do a great job of explaining how developers can use scope types to implement a consistent policy enforcement layer like what Melanie described earlier.
We have a section of the contributor guide dedicated to other OpenStack developers and how they can use various identity concepts effectively. I added a section [1] that tries to condense everything we went through in IRC, but it's really two parts. The first is why it's important and the second describes the process of migrating from legacy enforcement patterns to something using the new tools and default roles provided through keystone.
[0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-ke... [1] https://review.openstack.org/#/c/638563/
-melanie
[2] https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb744606431...