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....@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 [cl...@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-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 > -- Adam Heczko Security Engineer @ Mirantis Inc.
__________________________________________________________________________ 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
