Open Stack

On 2/20/19 2:13 AM, melanie witt wrote:
> On Tue, 19 Feb 2019 10:42:32 -0600, Matt Riedemann
> <mriedemos at 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?
>>
>> [1] https://review.openstack.org/#/c/433037/
>
> 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-keystone.2019-02-20.log.html#t2019-02-20T18:35:06
[1] https://review.openstack.org/#/c/638563/

>
> -melanie
>
> [2]
> https://github.com/openstack/nova/blob/3548cf59217f62966a21ea65a8cb744606431bd6/nova/api/openstack/compute/servers.py#L425
>
>
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190225/1f250ca1/attachment-0001.sig>