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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
