Re: [openstack-dev] [neutron][metadata] Is there HTTP attack issue in metadata proxy functionality offered by reference implementation?

[Morales, Victor]

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?

[Mathieu Gagné]

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?

[Clint Byrum]

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?

[huangdenghui]

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