openstack team mailing list archive

[Justin Santa Barbara <justin@xxxxxxxxxxxx>]

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
<vishvananda@xxxxxxxxx>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
>
>