Open Stack

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.