Open Stack

On Tue, 27 Nov 2018 08:32:40 -0800, Dan Smith wrote:
>>>> Change of ownership of resources
>>>> ================================
>>>> - Ignore the network piece for now, it's the most complicated. Being
>>>> able to transfer everything else would solve 90% of City Network's use
>>>> cases
>>>> - Some ideas around having this be a keystone auth-based access granting
>>>> instead of an update of project/user, but if keystone could hand user A
>>>> a token for user B, that token would apply to all resources of user B's,
>>>> not just the ones desired for transfer
>>>
>>> Whatever happened with the os-chown project Dan started in Denver?
>>>
>>> https://github.com/kk7ds/oschown
>>
>> What we distilled from the forum session is that at the heart of it,
>> what is actually wanted is to be able to grant access to a resource
>> owned by project A to project B, for example. It's not so much about
>> wanting to literally change project_id/user_id from A to B. So, we
>> asked the question, "what if project A could grant access to its
>> resources to project B via keystone?" This could work if it is OK for
>> project B to gain access to _all_ of project A's resources (since we
>> currently have no way to scope access to specific resources). For a
>> use case where it is OK for project A to grant access to all of
>> project B's resources, the idea of accomplishing this is
>> keystone-only, could work. Doing it auth-based through keystone-only
>> would leave project_id/user_id and all dependencies intact, making the
>> change only at the auth/project level. It is simpler and cleaner.
>>
>> However, for a use case where it is not OK for project B to gain
>> access to all of project A's resources, because we lack the ability to
>> scope access to specific resources, the os-chown approach is the only
>> proposal we know of that can address it.
>>
>> So, depending on the use cases, we might be able to explore a keystone
>> approach. From what I gathered in the forum session, it sounded like
>> City Network might be OK with a project-wide access grant, but Oath
>> might need a resource-specific scoped access grant. If those are both
>> the case, we would find use in both a keystone access approach and the
>> os-chown approach.
> 
> FWIW, this is not what I gathered from the discussion, and I don't see
> anything about that on the etherpad:
> 
>    https://etherpad.openstack.org/p/BER-change-ownership-of-resources
> 
> I know the self-service project-wide grant of access was brought up, but
> I don't recall any of the operators present saying that would actually
> solve their use cases (including City Network). I'm not really sure how
> granting another project access to all resources of another is really
> anything other than a temporary solution applicable in cases where
> supreme trust exists.
> 
> I could be wrong, but I thought they specifically still wanted an API in
> each project that would forcibly transfer (i.e. actually change
> userid/project on) resources. Did I miss something in the hallway track
> afterwards?

No, you didn't miss additional discussion after the session. I realize 
now from your and Tobias replies that I must have misunderstood the 
access grant part of the discussion. What I had interpreted when I 
brought up the idea of a keystone-based access grant was that Adrian 
thought it could solve their ownership transfer use case (and it's 
possible I misunderstood his response as well). And I don't recall 
Tobias saying something in objection to the idea, so I wrongly thought 
it could work for his use case too.

I apologize for my misunderstanding and muddying the waters for everyone 
on this.

Correcting myself: really what is wanted is to literally change 
project_id and user_id for resources, and that allowing the addition of 
another owner for a project's resources is not sufficient.

Best,
-melanie