On Thu, 3 Mar 2011, George Reese wrote: > Of all the boostrapping mechanisms I have encountered, the AWS model > still remains the best. Specifically, with the guest OS pulling the keys > from a trusted platform source. > > Any mechanism that requires an agent or requires any ability of the > hypervisor or cloud platform to inject a password creates trust issues. > In particular, the hypervisor and platform should avoid operations that > reach into the guest. The guest should have the option of complete > control over its data.
I completely agree with this. Generally, I can think of only 2 real needs of openstack in this regard. a.) needs to be able to accept some blob of data in the launch-instance API call, and make that data available to the instance in a private channel (such as the xen store). b.) needs to be able to read data that the instance writes to that channel and pass that data back through to a user who invokes some API call. Amazon gets along fairly well with just 'a' (the metadata service and 'user-data'). Additionally, theres is 1 time write only (you can only specify user-data on instance start, and cannot change it... other than with an instance stop and start). You can get by by simple api that allows the entity that launches the instance to make data available to the instance, and stop there. If you take a list of key and values that can be put in, it would even be better. For example, ec2 looks like this: $ ec2-run-instance ami-abcdeg --user-data="my. data here" The open stack could look like this: $ openstack-run-instance \ --data-user-data="my. data here" --data-admin-data="some other data here" The end result of which would be the metadata service having <source>/user-data : "my. data here" <source>/admin-data : "some other data here" In EC2 terms, what i'm really hoping for would be: http://169.254.169.254/latest/user-data http://169.254.169.254/latest/admin-data I think this is very powerful, and allows Rackspace to implement their initial password setting very easily via an installed guest agent. Ie, the guest comes up, the agent grabs http://169.254.169.254/latest/guest-agent-data that contains root_password : foo other-data here and more here it doesn't materr And then sets the root password. The above is very generic, easily re-purposed, and carries along the legacy Amazon user-data very easily. If you also make that data able to be updated via an API call, then you're even better off. That would allow the launcher to set the root password, verify it can get in to the instance, and then clear that data from the store so that it couldn't be seen again. Scott == small note == My primary interest in the key/value rather than just "value" in a single "user-data" (as Amazon has it) is that then only 1 party really has complete control of that user-data. For example, again, in the EC2 world, Rightscale wants to inject some data into the instance, and the user wants to inject some data into the instance. But both of these have to be shoved into that one 'user-data' field. So, you have to end up putting a multipart blob of data there and making both consumers aware that http://169.254.169.254/latest/user-data will not have exactly what they launched the instance with. _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp