Open Stack

Hi Kevin, thanks for bringing this up. Agree that with the current approach
to RBAC / ABAC model in OpenStack it is very challenging or nearly
impossible to securely do anything more complicated than just manually
spawn instance. I'm curious whether TC and/or the community could take
constructive approach and finally try to solve this during this or upcoming
dev cycles?


On Sat, Mar 11, 2017 at 10:46 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:

> 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
>
> __________________________________________________________________________
> 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
>



-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20170312/ce1d5845/attachment.html>