Re: [openstack-dev] [magnum] Use Keystone trusts in Magnum?

2016-07-07 Thread Johannes Grassler

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:jgrass...@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-
requ...@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-requ...@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

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


[openstack-dev] [magnum] Use Keystone trusts in Magnum?

2016-07-06 Thread Johannes Grassler

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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev