<div class="gmail_quote">Surely if you haven't got spoofing locked down on your cloud it's game over anyway?<div><br></div><div>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).</div>

<div><br></div><div>Then we could:</div><div><ul><li>Make OpenStack API calls from machine -> cloud without uploading a user's OpenStack credentials</li><li>Use Keystone to authenticate any other service you want your VM to talk to</li>

<li>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.</li><li>(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)</li>

</ul></div><div>I guess I just don't understand the dislike of using SSH.  Nothing we write is going to be any better.</div><div><br></div><div>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".</div>
<span class="HOEnZb"><font color="#888888">
<div><br></div><div>Justin</div></font></span><div class="HOEnZb"><div class="h5"><div><div><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 4:37 PM, Vishvananda Ishaya <span dir="ltr"><<a href="mailto:vishvananda@gmail.com" target="_blank">vishvananda@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>On Apr 10, 2012, at 4:24 PM, Justin Santa Barbara wrote:</div>
<br><blockquote type="cite"><blockquote class="gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div style="word-wrap:break-word">
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.</div></blockquote>


<div><br></div><div>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 (?)</div>


</blockquote><br></div></div><div>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.</div>

<div><br></div><div>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.</div>

<div><br></div><div>Vish</div><br></div></blockquote></div><br></div></div>
</div></div></div><br>