Open Stack

On 05/15/2015 11:12 AM, Fox, Kevin M wrote:
> And if its tied into nova, perhaps the service account password never is given to the vm, but the vm has a mechanism for fetching fresh keystone tokens, maybe a special url on the metadata server.
>
> Thanks,
> Kevin
> ________________________________________
> From: Fox, Kevin M
> Sent: Friday, May 15, 2015 7:56 AM
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action
>
> I think we have to be very careful with cheep, easy, user provisionable user accounts. I know we've had a hard enough time getting clouds to land at our organization because policies had to be adapted. I think the policies around User account allocation and particularly password strength, password rotation and administratively disabling them, will be the biggest challenge to the policies yet.
>
> Now if it was kind of a different thing, "service accounts", that might be more palatable to the powers that be.
>
> Thanks,
> Kevin

I'd like service accounts to be tied in with X509 validation and not 
even be able to do Password.  We can use Barbican to do the actual X509 
issue.

Revocations might be an issue;  We need to make sure the Keystone server 
checks a CRL from Barbican.

Kerberos is a better option.  With FreeIPA, it is a viable alternative 
even for smaller deployments.


> ________________________________________
> From: Adam Young [ayoung at redhat.com]
> Sent: Thursday, May 14, 2015 8:38 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [Murano] [Mistral] [Zaqar] [Keystone] SSH workflow action
>
> On 05/12/2015 09: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.
> Yeah, we need Authorization as a Service.  Was discussing this earlier
> today;  how do we assign Admin for Wordpress without accidentally
> granting the user the ability to create new virtual machines or networks.
>
> One part is namespacing of roles.  Nova:admin vs wordpress:admin.
>
> User would also need to be able to register new policy enforcement
> points for the code.  These would be predefined for big applications
> (Wordpress) but would have to be well thought out for others.
>
> I also don't think we want to make users get a token before perform
> every action.  THe apps should be able to query the information they
> need from Keystone when the user comes in.  It is a combination of
> Fedeartion, mapping, list_roles-for_user_and_project and extending of
> policy.
>
> I'm sure this will come up next week.
>
>
>>> 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.
> I think the user accounts (or consumers as oauth calls them) should be
> cheap, and easy to create .  I see no reason to try to limit them.
> Ideally, we would use something like X509 in order for them to talk to
> Keystone;  that work is under way in Keystone already. Kerberos works
> for those who want to use it with a Keytab.
>
>> 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.
> Why Oslo oand not Keystone?  Why do we need a new abstraction?
>
>>> 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 :)
>>
> Endpoint binding of tokens is proposed already.  I have a spec out for
> more constraints.  We need a way to annotate them in the token, and then
> policy can certainly be enforced on any data in the token.
>
> I suspect that what we will have is a two pass policy check;  the first
> will be all global options (endpoint binding, etc) and the second will
> be API specific checks.
>
>> 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
>
> __________________________________________________________________________
> 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
>
> __________________________________________________________________________
> 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