Surely if you haven't got spoofing locked down on your cloud it's game over anyway?
I think we do have another potential requirement here though: it would be great to get a "machine" Keystone token securely. I think it would also be nice to be able to get the machine's automatically generated SSH key fingerprint (although parsing the console log does work). Then we could: - Make OpenStack API calls from machine -> cloud without uploading a user's OpenStack credentials - Use Keystone to authenticate any other service you want your VM to talk to - Make SSH calls to the machine securely, to run anything we want e.g. install the management software of your choice, mount a disk etc. - (For symmetry, we could sign calls from the machine using our SSH key as well, but I don't think this is useful in practice) I guess I just don't understand the dislike of using SSH. Nothing we write is going to be any better. In particular, a secure distributed fault tolerant key-value store that nodes can read and write for any purpose, that we write from scratch as part of nova, seems a little "ambitious". Justin On Tue, Apr 10, 2012 at 4:37 PM, Vishvananda Ishaya <vishvana...@gmail.com>wrote: > On Apr 10, 2012, at 4:24 PM, Justin Santa Barbara wrote: > > One advantage of a network metadata channel is it allows for >> communication with cloud provider services without having to put a key into >> the vm. In other words, the vm can be authenticated via its ipv6 address. >> > > Did you have a use case in mind here? It seems that Keystone could use > the IPV6 address to authenticate an instance without having to upload > credentials, which would indeed be useful (e.g. for auto-scaling), but I > don't see why that needs any special metadata support (?) > > > Arbitrarily allowing keystone to authenticate ipv6 would be vulnerable to > spoofing. You need a channel direct from guest-host-keystone to be sure.. > I think authentication is the main concern, because if auth is over a > secure channel, then you can do all of the other communication over the > regular internet. The vm could connect to the control domain for a service > by subscribing to a message queue (for example) via a public ip. > > You could also secure the channel by having a private network attached to > the vm and only putting the control domain for the service on the private > network. Having keystone validate ipv6 only over that network might be an > option. > > Vish > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp