Proposes to remove keypair generation

This spec for blueprint keypair-generation-removal proposes to
drop support for POST /os-keypairs to generate a keypair.

APIImpact

Change-Id: I0e7b1bf513de5fad978f4bf71e3b7e14c6eefe6c
This commit is contained in:
Sylvain Bauza 2022-05-02 18:50:03 +02:00
parent d345f4dbd4
commit bf95c8287c
1 changed files with 220 additions and 0 deletions

View File

@ -0,0 +1,220 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
===============================================
Remove the API support for generating a keypair
===============================================
https://blueprints.launchpad.net/nova/+spec/keypair-generation-removal
As agreed on the last PTG, given RSA-SHA1 support is removed from recent OSes,
we prefer to remove the possibility to generate a keypair directly by Nova and
just be able to import a public key.
Problem description
===================
During the Yoga release, we triaged an open bug report [1]_ which noted
the fact that OpenSSH 8.8 removed support for RSA/SHA1 signatures
[2]_. As a result of this change in OpenSSH behavior, keypairs generated by
Nova are incompatible with recent guest OSes like CentOS9.
This leads to guests that are inaccessible via SSH using the created keypairs.
The consensus of the Nova community during the last PTG was to remove the
generation of keypairs from the ``os-keypairs`` API.
Use Cases
---------
As a user, I want to ssh to my instance without getting problems because I
generated a keypair.
As an admin, I want a seamless experience for my users and I let them to
generate their own keypairs depending on the images they want.
Proposed change
===============
We'll propose a new API microversion that will force the user to send a
public key.
Accordingly, the JSON request schema of POST /os-keypairs will look like this :
.. code-block:: python
create_v2XX = {
'type': 'object',
'properties': {
'keypair': {
'type': 'object',
'properties': {
'name': parameter_types.name,
'type': {
'type': 'string',
'enum': ['ssh', 'x509']
},
'public_key': {'type': 'string'},
'user_id': {'type': 'string'},
},
'required': ['name', 'public_key'],
'additionalProperties': False,
},
},
'required': ['keypair'],
'additionalProperties': False,
}
The JSON response will also change as we no longer generate private keys :
* ``private_key`` will never be returned from that microversion
Given we'll create a new microversion, we'll also use it for allowing
``. (dot)`` and ``@ (at)`` characters for the keypair name as it was accepted
on a previous spec for Xena [3]_.
This will mean that we will modify the _validate_new_key_pair() method to
accept those parameters only if wanted (which also means we will move this
method to the keypairs specific API module).
Alternatives
------------
For API interoperability reasons, we would have had to also create a new API
microversion if we wanted to support a new keypair type, eg. edcsa, which
defeats the purpose of simplicity.
Data model impact
-----------------
None.
REST API impact
---------------
All the details are already described above. The response will only drop the
meaningless private_key value as we continue to return a keypair with its
signature.
No policy changes are identified, as we only drop support for a capability.
Security impact
---------------
We'll improve security, for sure, by not letting Nova to create keypairs that
are disabled by OS policy due to the flaws of SHA-1 (even if ssh-rsa can
verify keys with SHA-256 hash algorithm) [4]_.
Notifications impact
--------------------
None.
Other end user impact
---------------------
novaclient and openstackclient new releases will remove support for generating
a keypair if you opt-in for the recent server microversion.
Performance Impact
------------------
None.
Other deployer impact
---------------------
None.
Developer impact
----------------
None.
Upgrade impact
--------------
None.
Implementation
==============
Assignee(s)
-----------
Primary assignee:
sylvain-bauza
Feature Liaison
---------------
None.
Work Items
----------
* write the API change.
* amend documentation and tests.
* write novaclient, openstacksdk and openstackclient support for this.
Dependencies
============
None.
Testing
=======
Unittests for sure, but we'll also need to modify Tempest to generate
the keypair by itself and import it into Nova. Thanks to the FIPS support we
already have, a conditional in Tempest already pre-generates a keypair and
tampers the payload by adding the generated public key [5]_, so we should just
make it default in our upstream jobs.
Documentation Impact
====================
None, besides API documentation.
References
==========
* .. [1] https://bugs.launchpad.net/nova/+bug/1962726
* .. [2] https://www.openssh.com/txt/release-8.8
* .. [3] https://specs.openstack.org/openstack/nova-specs/specs/xena/approved/allow-special-characters-in-keypair-name.html
* .. [4] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and
Application to the PGP Web of Trust" Leurent, G and Peyrin, T
(2020) https://eprint.iacr.org/2020/014.pdf
* .. [5] https://github.com/openstack/tempest/blob/c545cb1c7c14d36d2bc65a55ec13e0c6cd095425/tempest/lib/services/compute/keypairs_client.py#L81-L88
History
=======
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* - Zed
- Introduced