← Back to team overview

openstack team mailing list archive

Metadata and File Injection (code summit session?)

 

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

References