[openstack-dev] [nova] Using image metadata to sanity check supplied authentication data at nova 'create' or 'recreate' time?

Gregory Haynes greg at greghaynes.net
Mon Jun 6 22:46:38 UTC 2016

On Mon, Jun 6, 2016, at 05:44 PM, Gregory Haynes wrote:
> On Mon, Jun 6, 2016, at 05:31 PM, Michael Still wrote:
>> On Tue, Jun 7, 2016 at 7:41 AM, Clif Houck <me at clifhouck.com> wrote:
>>> Hello all,
>>> At Rackspace we're running into an interesting problem: Consider
>>> a user
>>> who boots an instance in Nova with an image which only supports SSH
>>> public-key authentication, but the user doesn't provide a public
>>> key in
>>> the boot request. As far as I understand it, today Nova will happily
>>> boot that image and it may take the user some time to realize their
>>> mistake when they can't login to the instance.
>> What about images where the authentication information is inside the
>> image? For example, there's just a standard account baked in that
>> everyone knows about? In that case Nova doesn't need to inject
>> anything into the instance, and therefore the metadata doesn't need
>> to supply anything.
> We have an element in diskimage-builder[1] which allows a user to pass
> a kernel boot param to inject an ssh key if needed due to a reason
> like this. Obviously, this wouldn't 'just work' in any normal cloud
> deploy since the kernel boot params are baked in to the image itself
> (this is currently useful to ironic users who boot ramdisks) but maybe
> the pattern is helpful: Check something once at boot time via init
> script and that's it. The downside being that a user has to reboot the
> image to inject the key, but IMO its a huge decrease in complexity
> (over something like file injection) for something a user who just
> booted a new image should be OK with.
> Cheers,
> Greg
Looks like I left out the actual useful info:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160606/d3d6c6d1/attachment.html>

More information about the OpenStack-dev mailing list