tpepper
commented
8 years ago This is generally normal paradigm out there, but it does mean that we would need to allow storing some key:value pairs in the identity service on the behalf of a user.
OpenStack's implementation is described at http://docs.openstack.org/user-guide/cli-nova-configure-access-security-for-instances.html and in that context one creates these keys and Nova itself stores them, such that when running a workload you can reference the key you want authorized for a VM, without actually having to put it in a cloud-init.
Similar happens if you're using Rackspace. You upload keys, then when starting a machine, you reference the key from your set of keys that you want associated with the machine, eg: https://developer.rackspace.com/docs/rack-cli/services/examples/servers/
One might question if storing a name:public-key pair on behalf of a user is a security problem. I don't see it as any more risk than storing the userid:password in the identity service. And it's a useful convenience.
Similarly if the user doesn't need to actually make a key themselves, that's an additional convenience. I can imagine an optional flag for --ephemeral-key in the instance creation CLI, with the key generated by ciao-cli and returned to the user.
Beyond the above conceptual reasoning, there appears to be one major problem: based on conversations at OpenStack summit in Austin 2016 and looking at the keystone identity API, I don't see a way to store key:value pairs on the behalf of the user. Which I presume is why the Nova folks were grumbling about the need to do this themselves or convince Keystone to add an API for this. Some Nova folks argued this key identity data should be stored in the identity service, not the scheduler...which makes perfect sense. For Ciao we strongly prefer that route, but that would mean we must implement and use a nonstandard identity service.
I think similarly we want to be able to store user generated cloud-init files on the users' behalf and overall workload descriptions. Right now these are statically defined in csv and yaml files in the controller code base. Where we store per-tenant and per-user workload details needs design/architecture, and then this identity key feature could simply be a part of that.
There should be API support for handling SSH public keys for easier access to VMs. This issue has two components:
1) the ability to upload an existing SSH public key for reuse in VMs that are created. This would involve creating a store for public key so that a user could reference their already uploaded public keys to be added to the authorized keys file on VMs. The reference should likely be a user readable value since the available keys would be limited to the specific user.
2) for testing purposes, adding the ability to generate a new key that would do a ssh key-gen and upload the public key to the above key store and provide the private key in the response. This would allow for testing without a hard-coded common public key.