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....@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
