Open Stack

I would agree some kind of keystone support would be great. Whether its the right solution for the barbican/vm workflow though, I'm not as sure.

You can have a look at the implementation if you'd like. It does not copy any Keystone code. It does use Keystone's token signing code though to create a signed message between nova and barbican.

The full review is here:
https://review.openstack.org/#/c/159573/

Relevant bits are creating signed token:
https://review.openstack.org/#/c/159573/5/barbican/plugin/vendordata_barbican.py which calls:
https://review.openstack.org/#/c/159573/5/barbican/token.py

and verifying token:
https://review.openstack.org/#/c/159573/5/barbican/api/middleware/context.py

Pretty simple stuff really.

Thanks,
Kevin
________________________________________
From: Douglas Mendizábal [douglas.mendizabal at rackspace.com]
Sent: Thursday, May 14, 2015 4:09 PM
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

+1 to a Keystone and Oslo solution for this problem.  One of my
objections to Kevin's spec for Barbican is the copying of Keystone
code into the Barbican tree.  It seems to me like a "code smell" that
we're trying to solve a problem that Keystone should be solving.

Like I mentioned in the other thread [1]  I would be willing to
schedule this discussion during one of the Barbican Working Sessions.

I'm also very interested in learning more about the Policy work being
done, since we recently did a lot of work to provide additional
policies for some of our contributors who find the current Keystone
models "burdensome". [2]

- - Douglas Mendizábal

[1]
http://lists.openstack.org/pipermail/openstack-dev/2015-May/064196.html

[2]
http://specs.openstack.org/openstack/barbican-specs/specs/kilo/add-creat
or-only-option.html

On 5/12/15 8:43 PM, Zane Bitter wrote:
> On 12/05/15 13:06, Georgy Okrokvertskhov wrote:
>> There is one thing which still bothers me. It is authentication.
>> Right now with separate RabbitMQ instance we keep VMs
>> authentication isolated from OpenStack infra. This is still a
>> problem if you want to use webhooks (Heat autoscaling, Murano
>> actions) via our own authentication models. If we plan to use
>> Zaqar it will be interesting to know how Zaqar solves this
>> issue.
>
> Aha, if you'd read my blog post you would know the answer ;)
>
> There's no specific provision for this in Zaqar at the moment
> AFAIK. The problem is really Keystone: it was never designed for
> authenticating applications to the cloud, only real live users.
>
> We need to fix this, in Keystone & Oslo, for the benefit of all
> application-facing services. Some work has already started:
>
> - Keystone can now support separate backends for separate domains,
> so even if you are backed by read-only LDAP you can create service
> users in a separate DB-backed domain:
> http://adam.younglogic.com/2014/08/getting-service-users-out-of-ldap/
>
>  - Work is planned on "Dynamic Policy" to make the authorisation
> model more powerful:
> http://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/
>
> I'm not sure that this goes far enough though (although I don't
> completely grok the implications of Dynamic Policy). We really
> want users to be able to define their own policy for application
> accounts that they create, and at an even more fine-grained level,
> so a common library for this sort of authorisation would be
> helpful.
>
>> Frankly, I don't think that this is a good idea to use Keystone
>> credentials or tokens for MQ clients on VMs. This topic,
>> probably, deserves its own e-mail thread.
>
> Keystone credentials _are_ the answer, but they must not be the
> *user's* Keystone credentials.
>
> I can tell you how Heat does this right now for authenticating
> application callbacks for WaitConditions. It's not exactly pretty,
> but it works. Basically we create the application users in a
> separate domain and then do extra authorisation checks ourselves.
> Steve Hardy wrote a comprehensive summary on his blog:
> http://hardysteven.blogspot.com/2014/04/heat-auth-model-updates-part-2
- -stack.html
>
>
>
> So the mechanisms are there. In the short term we'd need some
> cross-project co-operation to define a system through which we can
> do this across projects (i.e. Murano or any other service can
> create a user and have Zaqar authorise it for listening on a
> particular queue). Maybe this is an extra parameter when creating a
> queue in Zaqar to also create a user account in a separate domain
> (the way Heat does) with permission to send and/or receive only on
> that particular queue and return its credentials. That would be
> easier to secure and easier to implement than having other services
> create the user accounts themselves.
>
> In the medium term hopefully we'll be able to come up with a less
> hacky solution that uses Oslo libraries to manage all of the user
> creation and authorisation.
>
>> It will be interesting to discuss this with Keystone team. What
>> is it is possible to have a token which is restricted to be
>> authenticated to specific API URL like  GET
>> /v1/queues/<queue-id>/
>
> Yes, we should definitely discuss this with the Keystone team and
> make sure they're getting feedback from all of the many groups who
> need it so that they can prioritise the work appropriately :)
>
> cheers, Zane.
>
>>
>> Thanks Gosha
>>
>>
>>
>> On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M
>> <Kevin.Fox at pnnl.gov <mailto:Kevin.Fox at pnnl.gov>> wrote:
>>
>> +1 ________________________________________ From: Zane Bitter
>> [zbitter at redhat.com <mailto:zbitter at redhat.com>] Sent: Monday,
>> May 11, 2015 6:15 PM To: openstack-dev at lists.openstack.org
>> <mailto:openstack-dev at lists.openstack.org> Subject: Re:
>> [openstack-dev] [Murano] [Mistral] SSH workflow action
>>
>> Hello!
>>
>> This looks like a perfect soapbox from which to talk about my
>> favourite issue ;)
>>
>> You're right about the ssh idea, for the reasons discussed
>> related to networking and a few more that weren't (e.g. users
>> shouldn't have to and generally don't want to give their private
>> SSH keys to cloud services). I didn't know, or had forgotten,
>> about the message queue implementation in Murano and while I
>> think that's the correct shape for the solution, as long as the
>> service in question is not multi-tenant capable it's a
>> non-starter for a public clouds at least and probably many
>> private clouds as well (after all, if you don't need
>> multi-tenancy then why are you using OpenStack?).
>>
>> There's been a tendency within the application-facing OpenStack
>> projects to hack together whatever local solutions to problems
>> that we can in order to make progress without being held up by
>> other projects. Let's take a moment to acknowledge that Heat is
>> both the earliest and the biggest offender here, and that I am as
>> culpable as anyone in the current state of affairs. There are
>> multiple reasons for how things have gone - part of it is that it
>> turned out we developed services in the wrong order, starting at
>> too high a level. Part of it, frankly, is due to that element of
>> the community that maintains a hostile position toward
>> application-facing services and have used their influence in the
>> community to maintain a disincentive against integrating
>> projects together.[1] (If deployment of your project is
>> discouraged that's one thing, but if it depends on another
>> project whose deployment is also being discouraged then the
>> hurdle you have to jump over is twice the height.)
>>
>> That said, I think we're at the point where we are hurting
>> ourselves more than anyone else is by failing to come up with
>> coherent, cross-project solutions.
>>
>> The problem articulated in this thread is not an isolated one.
>> It's part of a more general pattern that affects a lot of
>> projects: we need a way for the cloud to communicate to
>> applications running in it. Angus started a recent discussion of
>> this already on the list.[2] The requirements, IMHO, are
>> roughly:
>>
>> * Reliability - we must be able to guarantee delivery to
>> applications * Asynchrony - the cloud cannot block on
>> user-controlled processes * Multitenancy - this is table stakes
>> for OpenStack * Access control - even within tenants, we need to
>> trust guest VMs minimally
>>
>> IMNSHO Zaqar messages are the obvious choice for the transport
>> here. (Or something very similar in shape to Zaqar - but it'd be
>> much better to join forces with the Zaqar team to improve it
>> where necessary than to start a new project.) I really believe
>> that if we work together to come up with consistent solutions to
>> these problems that keep popping up across OpenStack, we can
>> prove wrong all the naysayers who think that application-facing
>> services are only for proprietary clouds. I wrote up my vision
>> for why that's important and what there first steps are here:
>>
>> http://www.zerobanana.com/archive/2015/04/24#a-vision-for-openstack
>>
>>
>>
Note that there are some subtleties that not everyone here will be
>> able to contribute directly to fixing. For example, as I
>> highlight in that post, Keystone is built around the concept that
>> applications never talk to the cloud. But there are lots of other
>> things people can work on now that would really make a big
>> difference. For Mistral and Murano specifically, and in rough
>> order of priority:
>>
>> * Add an action in Mistral for sending a message to a Zaqar
>> queue. This is easy and there's no reason you couldn't do it
>> right now. * Encourage any deployers and distributors you know
>> (or, ahem, may work for ;) to make Zaqar available as an option.
>> * Add a way to trigger a Mistral workflow with a Zaqar message.
>> This is one piece in the puzzle to build user-configurable
>> messaging flows between OpenStack services.[3] * Make Zaqar an
>> alternative to Rabbit for communicating to the Murano agent. *
>> Use your experience in implementing notifications over email and
>> the like in Mistral to help the Zaqar team to add the
>> notification features they've long been planning. These could
>> take the form of microservices listening on a Zaqar queue. You
>> get the reliable, asynchronous queuing semantics for free and
>> *every* service and user can benefit from your work.
>>
>> Imagine if there were one place where we implemented reliable
>> queuing semantics at cloud scale, and when we added e.g.
>> long-polling or WebSockets everyone could benefit immediately.[4]
>> Imagine if there were one place for notifications, at cloud
>> scale, for operators to secure. (How many webhook implementations
>> are there in OpenStack right now? How many of them are actually
>> secure against malicious users?) One format for messages between
>> services so that users can connect up their own custom pipelines.
>> We're not that far away! All of this is within reach if we work
>> together.
>>
>> Thanks for reading. Please grab me at summit if you want to know
>> more; I am always happy to bend the ear of anyone who will listen
>> at length on this topic. As usual, I'll be the tall dude with the
>> weird accent ;)
>>
>> cheers, Zane.
>>
>>
>> [1] https://review.openstack.org/#/c/180112/ [2]
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/060748.
html
>>
>>
[3]
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062617.
html
>>
>>
[4]
>>
>> http://lists.openstack.org/pipermail/openstack-dev/2015-April/062619.
html
>>
>>
>>
>>
On 06/05/15 11:42, Filip Blaha wrote:
>>> Hello
>>>
>>> We are considering implementing  actions on services of a
>>> murano environment via mistral workflows. We are considering
>>> whether
>> mistral
>>> std.ssh action could be used to run some command on an
>>> instance.
>> Example
>>> of such action in murano could be restart action on Mysql DB
>> service.
>>> Mistral workflow would ssh to that instance running Mysql and
>>> run "service mysql restart". From my point of view trying to
>>> use
>> SSH to
>>> access instances from mistral workflow is not good idea but I
>>> would like to confirm it.
>>>
>>> The biggest problem I see there is openstack networking.
>>> Mistral
>> service
>>> running on some openstack node would not be able to access
>> instance via
>>> its fixed IP (e.g. 10.0.0.5) via SSH. Instance could accessed
>> via ssh
>>> from namespace of its gateway router e.g. "ip netns exec
>> qrouter-... ssh
>>> cirros at 10.0.0.5 <mailto:cirros at 10.0.0.5>" but I think it is
>>> not
>> good to rely on implementation
>>> detail of  neutron and use it. In multinode openstack
>> deployment it
>>> could be even more complicated.
>>>
>>> In other words I am asking whether we can use std.ssh mistral
>> action to
>>> access instances via ssh on theirs fixed IPs? I think no but I
>> would
>>> like to confirm it.
>>>
>>> Thanks Filip
>>>
>>>
>>
>> _____________________________________________________________________
_____
>>
>>
>>
> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe:
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>
>> <http://OpenStack-dev-request@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://OpenStack-dev-request@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://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
>
>>
>>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>>
>> -- Georgy Okrokvertskhov Architect, OpenStack Platform Products,
>> Mirantis http://www.mirantis.com <http://www.mirantis.com/> Tel.
>> +1 650 963 9828 Mob. +1 650 996 3284
>>
>>
>> _____________________________________________________________________
_____
>>
>>
>>
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
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVVSsxAAoJEB7Z2EQgmLX7mlIP/3N5miOjHIo7acpPuEJZazpF
VbBLPS9xWTsWJ7msimcRmwPbPualSHF3vtaJ+9UfnKaQK6mIKVTrDYcRT5kmTSFR
cgnMEj9H0pK8zT0cBZ+WQXitzB9LDrKQFzs3xtaPPl2wxy0hxj+O+lIQ+RykftqD
YeQXAofpKMKCspcvXrMKvdoWYbM28vSbqCBSI7lxmeI9HGEHYaDSg/vf/FLp0f6f
o9pB4XtbGyXWbDNIj8gBuCSxOxPP/Sl4LecllKRKk38BlS8nhqHUITQA13POoRS+
+vUlRitNyCH0A7/i7QYiPDrLYOETh+1jflPwhdd2kqoHfIM67YcpMVDe+us4DSQr
lvUUBzaGiqZ9byOu/hCDTvgkC76MAV6A7BagYOh9eyQh6uHRu659avdblFT8P8CQ
c2oVBhMjRbv2adG/mcsMjPAUp5hG9RCr/9Ty+yAbQYTN5nt4ZgjubqemkdXK7Riq
EAC96u+Mn/KeQqU/XReZRtmt+cbjQPLamzki9RSLnpNfmBgxvZU3FiF2tq3/w82G
teYMFOZ1gcaaZcPTAzGWUA9WSJOHDGGxzE3Tuq8tCAKd5B8e2QotfMOtO8ux1ZxX
pmBc8i4+98mbtQ3U2ZCM2WgtvuGFr6n3XY7gx6qmwtk/zUhlTZiWD3KKz++T7pgV
Osl3ewuZRPGTNPF3m/bh
=GIDj
-----END PGP SIGNATURE-----

__________________________________________________________________________
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