Re: [openstack-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?
Thant’s remind me when we tried to improve cloud-init. Basically, the discovery process checks sequentially where the instance is being landed(EC2, GoogleCompute, OpenStack). This process could be done in parallel and reduce the time to boot. Regards, Victor Morales On 11/16/16, 11:31 AM, "Mathieu Gagné" wrote: >On Wed, Nov 16, 2016 at 11:52 AM, Clint Byrum wrote: >> >> IMO the HTTP metadata service and the way it works is one of the worst >> ideas we borrowed from EC2. Config drive (which I didn't like when I >> first saw it, but now that I've operated clouds, I love) is a simpler >> system and does not present any real surface area to the users. >> > >Cannot agree more with you on that one. > >-- >Mathieu > >__ >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
Re: [openstack-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?
On Wed, Nov 16, 2016 at 11:52 AM, Clint Byrum wrote: > > IMO the HTTP metadata service and the way it works is one of the worst > ideas we borrowed from EC2. Config drive (which I didn't like when I > first saw it, but now that I've operated clouds, I love) is a simpler > system and does not present any real surface area to the users. > Cannot agree more with you on that one. -- Mathieu __ 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
Re: [openstack-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?
Excerpts from huangdenghui's message of 2016-11-17 00:05:39 +0800: > hi > Currently, nova metadata service is proxy by metadata agent in dhcp agent > or l3 router agent, it is depended on whether network attach to router or > not. In essential, metadata agent implements a http proxy functionality by > computer node host protocal stack. In other words, it exposes host protocol > stack to vm. If vm is a attacker, it can launch a HTTP GET flood attacks. > then it may affect this computer node. I would like to hear you guy's > opinion. any comment is welcome. thanks. Yes, it's an attack vector and should be protected and monitored as such. IMO the HTTP metadata service and the way it works is one of the worst ideas we borrowed from EC2. Config drive (which I didn't like when I first saw it, but now that I've operated clouds, I love) is a simpler system and does not present any real surface area to the users. __ 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-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?
hi Currently, nova metadata service is proxy by metadata agent in dhcp agent or l3 router agent, it is depended on whether network attach to router or not. In essential, metadata agent implements a http proxy functionality by computer node host protocal stack. In other words, it exposes host protocol stack to vm. If vm is a attacker, it can launch a HTTP GET flood attacks. then it may affect this computer node. I would like to hear you guy's opinion. any comment is welcome. thanks. __ 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