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

Jim Rollenhagen jim at jimrollenhagen.com
Tue Jun 7 13:37:25 UTC 2016

On Tue, Jun 07, 2016 at 08:31:35AM +1000, 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.

Right, so that's a third case. How I'd see this working is maybe an
image property called "auth_requires" that could be one of ["none",
"ssh_key", "x509_cert", "password"]. Or maybe it could be multiple
values that are OR'd, so for example an image could require an ssh key
or an x509 cert. If the "auth_requires" property isn't found, default to
"none" to maintain compatibility, I guess.

The bigger question here is around hitting the images API syncronously
during a boot request, and where/how/if to cache the metadata that's
returned so we don't have to do it so often. I don't have a good answer
for that, though.

// jim

> Cheers,
> Michael
> -- 
> Rackspace Australia

> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

More information about the OpenStack-dev mailing list