Open Stack

On Fri, 13 Dec 2013, Fox, Kevin M wrote:

> 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.

For what its worth, the same general problem is solved by just putting a
null route to the metadata service. cloud-init has a config option for
doing this.  After route has put such a route in place, you should
effectively be done.

  http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
  # remove access to the ec2 metadata service early in boot via null route
  #  the null route can be removed (by root) with:
  #    route del -host 169.254.169.254 reject
  # default: false (service available)
  disable_ec2_metadata: true

I've also considered before that it might be useful for the instance to
make a request to the metadata service that its done and that the data can
now be deleted.