Open Stack

Ah, good point.

So, disabling the route wouldn't work if you wanted to use the metadata proxy for ongoing events for the guest agent.

But the nonce option would would work.

Another option would be to add a 169.254.169.254/metadata/disable url that disables that part of the proxy after cloud-init runs. Then no further metadata can be read until the next boot.

Kevin

________________________________________
From: Clint Byrum [clint at fewbar.com]
Sent: Friday, December 13, 2013 11:46 AM
To: openstack-dev
Subject: Re: [openstack-dev] Unified Guest Agent proposal

Excerpts from Fox, Kevin M's message of 2013-12-13 11:32:01 -0800:
> Hmm.. so If I understand right, the concern you started is something like:
>  * You start up a vm
>  * You make it available to your users to ssh into
>  * They could grab the machine's metadata
>
> I hadn't thought about that use case, but that does sound like it would be a problem.
>
> Ok, so... the problem there is that you need a secrets passed to the vm but the network trick isn't secure enough to pass the secret, hence the config drive like trick since only root/admin can read the data.
>
> Now, that does not sound like it excludes the possibility of using the metadata server idea in combination with cloud drive to make things secure. You could use cloud drive to pass a cert, and then have the metadata server require that cert in order to ensure only the vm itself can pull any additional metadata.
>
> The unified guest agent could use the same cert/server to establish trust too.
>
> Does that address the issue?
>

There is still no need for cloud drive.

cloud-init can drop the route to the metadata network once it has fetched
this data, but before it has enabled SSHD by generating host keys.

Or you can just treat everything in that metadata as compromised already,
and just use a nonce to create a trust relationship with newly fetched
secrets stored as root on the box.

This is already a solved problem.

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev