Open Stack

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.

I've been thinking about a solution to this problem. Ideally, the Nova
API would quickly return an HTTP code indicating a problem with the
request and reject the `create` or `recreate` request if the proper
credentials were not included as part of the request.

So in the example above, instead of Nova accepting the create request,
Nova would check the requested image's meta-data and ensure at least
one form of authentication is supported AND has credentials available
to place on the image during provisioning. Basically, ensure the
requester has a way to login remotely.

I've put up a short specification on this proposed addition here:
https://review.openstack.org/#/c/326073/
and the blueprint is here:
https://blueprints.launchpad.net/nova/+spec/auth-based-on-image-metadat
a

I think one of the glaring weaknesses of this proposal is it would
require a call to the image API to get image meta-data during `create`
or `recreate`. This could be alleviated by caching image meta-data in
Nova, since I wouldn't expect image meta-data to change often.

There's also the question of the image meta-data itself. I don't think
there is any existing standard to describe, using metadata, what remote
login/authentication methods a particular image supports. One way could
be to provide a set of configuration options for the operator to
define. That way, each operator could define their own metadata
describing each authentication method supported by their images.

Hoping this will elicit some opinions on how to go about solving this,
or if I've missed something that already exists that solves this
problem.

Any thoughts welcome.

Thanks,
Clif Houck