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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
