Open Stack

Hello,

On 07/06/2016 09:52 PM, Hongbin Lu wrote:
> Magnum generates Keystone trust for each bay: https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay . Possibly, you can reuse the trust stored in the bay for this purpose.

Oh...good to know that, thanks! That would make it a lot easier. I'll give it a try...

Cheers,

Johannes


> Best regards,
> Hongbin
>
>> -----Original Message-----
>> From: Johannes Grassler [mailto:jgrassler at suse.de]
>> Sent: July-06-16 9:40 AM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [magnum] Use Keystone trusts in Magnum?
>>
>> Hello,
>>
>> I submitted https://review.openstack.org/#/c/326428 a while ago to get
>> around having to configure Heat's policy.json in a very permissive
>> manner[0]. I naively only tested it as one user, but gating caught that
>> omission and dutifully failed (a user cannot stack-get another user's
>> Heat stack, even if it's the Magnum service user). Ordinarily, that is.
>>
>> Beyond the ordinary, Heat uses[1] Keystone trusts[2] to handle what is
>> basically the same problem (acting on a user's behalf way past the time
>> of the stack-create when the token used for the stack-create may have
>> expired already).
>>
>> I propose doing the same thing in Magnum to get the Magnum service user
>> the ability to perform a stack-get on all of its bays' stacks. That way
>> the hairy problems with the wide-open permissions neccessary for a
>> global stack-list can be avoided entirely.
>>
>> I'd be willing to implement this, either as part of the existing change
>> referenced above or with a blueprint and all the bells and whistles.
>>
>> So I have two questions:
>>
>> 1) Is this an acceptable way to handle the issue?
>>
>> 2) If so, is it blueprint material or can I get away with adding the
>> code
>>      required for Keystone trusts to the existing change?
>>
>> Cheers,
>>
>> Johannes
>>
>>
>> Footnotes:
>>
>> [0] See Steven Hardy's excellent dissection of the problem at the root
>> of it:
>>
>>       http://lists.openstack.org/pipermail/openstack-dev/2016-
>> July/098742.html
>>
>> [1] http://hardysteven.blogspot.de/2014/04/heat-auth-model-updates-
>> part-1-trusts.html
>>
>> [2] https://wiki.openstack.org/wiki/Keystone/Trusts
>>
>> --
>> Johannes Grassler, Cloud Developer
>> SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
>> GF: Felix Imendörffer, Jane Smithard, Graham Norton Maxfeldstr. 5,
>> 90409 Nürnberg, Germany
>>
>> _______________________________________________________________________
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


-- 
Johannes Grassler, Cloud Developer
SUSE Linux GmbH, HRB 21284 (AG Nürnberg)
GF: Felix Imendörffer, Jane Smithard, Graham Norton
Maxfeldstr. 5, 90409 Nürnberg, Germany