On 12/05/15 13:32, Fox, Kevin M wrote:
Barbican has the same issue. If Barbican is for storing secrets, how do you get a secret to the VM so it can get its secrets from Barbican? Aaarrrrggg! :)
Ah yes, I forgot about Barbican, but as another application-facing API it is indeed in the same boat as all of the others we've been talking about in this thread by the sound of it.
I've been working on a solution here: https://blueprints.launchpad.net/barbican/+spec/vm-integration We're planning on talking more about that spec at the summit though.
So just keep in mind that this problem is not in any way specific to Barbican.
If we can get Nova to automatically create a Keystone user account for every server and provide the credentials/token in the metadata, that would be awesome. Nova is the hardest place to get new features into though, so it might be wise to consider other options.
I've heard through the grape vine that Amazon lets you have a machine account that is associated with the vm. I'm not sure that's true or not, but some kind of keystone account integration into nova might help...
Yes, that's correct. EC2 provides a machine account for each VM, along with a rotating key (I guess equivalent to a token for our purposes) accessible through the metadata. You can dynamically assign roles to the machine user in order to control its access to all of the AWS API actions.
cheers, Zane.
Thanks, Kevin ------------------------------------------------------------------------ *From:* Georgy Okrokvertskhov [gokrokvertsk...@mirantis.com] *Sent:* Tuesday, May 12, 2015 10:06 AM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [Murano] [Mistral] SSH workflow action 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. 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. 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>/ Thanks Gosha On Tue, May 12, 2015 at 8:58 AM, Fox, Kevin M <kevin....@pnnl.gov <mailto:kevin....@pnnl.gov>> wrote: +1 ________________________________________ From: Zane Bitter [zbit...@redhat.com <mailto:zbit...@redhat.com>] Sent: Monday, May 11, 2015 6:15 PM To: openstack-dev@lists.openstack.org <mailto:openstack-dev@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@10.0.0.5 <mailto:cirros@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-requ...@lists.openstack.org?subject:unsubscribe <http://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://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://openstack-dev-requ...@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-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
