Open Stack

Nova needs to either: provide a vouching mechanism for VM's to always be able to get something that proves the VM is the VM, or provide a mechanism to securely give the VM a keystone token thats unique to the VM's. Its got to work and be secure through vm's that are stopped or suspended for significant periods of time then restarted, or snapshotted and relaunched several times, etc.... the exhaustive problem description is here:
https://review.openstack.org/#/c/222293/

Thanks,
Kevin

________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Friday, March 10, 2017 6:34 PM
To: openstack-dev
Subject: Re: [openstack-dev] [tc][appcat] The future of the App Catalog

Excerpts from Zane Bitter's message of 2017-03-10 19:09:42 -0500:
> On 10/03/17 12:27, Monty Taylor wrote:
> > On 03/10/2017 10:59 AM, Clint Byrum wrote:
> You may be familiar with the Kuryr project, which integrates Kubernetes
> deployments made by Magnum with Neutron networking so that other Nova
> servers can talk directly to the containers and other fun stuff. IMHO
> it's exactly the kind of thing OpenStack should be doing to make users'
> lives better, and give a compelling reason to install k8s on top of
> OpenStack instead of on bare metal.
>
> So here's a fun thing I learned at the PTG: according to the Magnum
> folks, the main thing preventing them from fully adopting Kuryr is that
> the k8s application servers, provisioned with Nova, need to make API
> calls to Neutron to set up the ports as containers move around. And
> there's no secure way to give Keystone authentication credentials to an
> application server to do what it needs - and, especially, to do *only*
> what it needs.
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-October/105304.html
>
> Keystone devs did agree in back in Austin that when they rejigger the
> default policy files it will done in such a way as to make the
> authorisation component of this feasible (by requiring a specific
> reader/writer role, not just membership of the project, to access APIs),
> but that change hasn't happened yet AFAIK. I suspect that it isn't their
> top priority. Kevin has been campaigning for *years* to get Nova to
> provide a secure way to inject credentials into a server in the same way
> that this is built in to EC2, GCE and (I assume but haven't checked)
> Azure. And they turned him down flat every time saying that this was not
> Nova's problem.
>
> Sorry, but if OpenStack isn't a good, secure platform for running
> Kubernetes on then that is a HAIR ON FIRE-level *existential* problem in
> 2017.
>

You're very right on this. And kuryr not working the way it should is _a
disaster_. I was hoping it had worked itself out by now.

I've argued against certain aspects of instance-users in the past (and
for others). I think it might be worth it to take another shot at
actually writing up a spec again.

In the mean time, we could always have shade inject instance-user
creds... <ducks under the shoe Monty's about to throw at him>

> We can't place too much blame on individual projects though, because I
> believe the main reason this doesn't Just Work already is that there has
> been an unspoken consensus that we needed to listen to users like you
> but not to users like Kevin, and the elected leaders of our community
> have done nothing to either disavow or officially adopt that consensus.
> We _urgently_ need to decide if that's what we actually want and make
> sure it is prominently documented so that both users and developers know
> what's what.
>
> FWIW I'm certain you must have hit this same issue in infra - probably
> you were able to use pre-signed Swift URLs when uploading log files to
> avoid needing credentials on servers allocated by nodepool? That's
> great, but not every API in OpenStack has a pre-signed URL facility, and
> nor should they have to.
>

Indeed, that's how infra nodes store logs in swift.

> (BTW I proposed a workaround for Magnum/Kuryr at the PTG by using a
> pre-signed Zaqar URL with a subscription triggering a Mistral workflow,
> and I've started working on a POC.)
>

What triggers the boot to kick over the bucket full of golf balls
though?

> > Considering computers as some-how inherently 'better' or 'worse' than
> > some of the 'cloud-native' concepts is hog wash. Different users have
> > different needs. As Clint points out - kubernetes needs to run
> > _somewhere_. CloudFoundry needs to run _somewhere_. So those are at
> > least two other potential users who are not me and my collection of
> > things I want to run that want to run in computers.
>
> I think we might be starting to talk about different ideas. The whole
> VMs vs. containers fight _is_ hogwash. You're right to call it out as
> such. We hear far too much about it, and it's totally unfair to the
> folks who work on the VM side. But that isn't what this discussion is about.
>
> Google has done everyone a minor disservice by appropriating the term
> "cloud-native" and using it in a context such that it's effectively been
> redefined to mean "containers instead of VMs". I've personally stopped
> using the term because it's more likely to generate confusion than clarity.
>
> What "cloud-native" used to mean to me was an application that knows
> it's running in the cloud, and uses the cloud's APIs. As opposed to
> applications that could just as easily be running in a VPS or on bare
> metal, but happen to be running in a VM provisioned by Nova.
>

+1 for "apps that know they're in the cloud", and further apps that know
how to talk to their cloud.

And also +1 for listening to folks who want a little more help in
interacting with their cloud from inside their VMs. If I've squelched
anyone in the past, well, times have changed. Let's get this done.

Also, thanks Zane, for actually answering directly the main question.
What would we change in Nova? We'd make it easier for vms to interact
with their cloud.

__________________________________________________________________________
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