API: Keypair support for X509 public key certificates
Nova keypairs are mostly used by Linux guests to handle user authentication via SSH public key authentication without incurring in the management and security overhead that passwords require.
Public keys are provided to the guests as part of the metadata and included in the guest configuration by tools like cloud-init.
Windows operating systems don't support natively SSH and thus authentication requires the usage of passwords unless the image deployer chooses to include a 3rd party unsupported SSH service port, which implies incurring in potential security and support issues.
Windows supports natively password-less authentication for WinRM by using X509 certificates in place of SSH keys, including Powershell remoting as detailed here: http://
From a practical perspective, X509 certificates are used by WinRM in a way which can be considered consistent with the usage of SSH keys on Linux, as both are based on public / private keypairs. For simplicity, since WinRM can be configured to accept self signed certificates, we will omit the implications of certificate chain validation.
While Nova currently supports SSH keypairs only, the API can be extended to support x509 certificates, while maintaining full backwards compatibility.
The areas that require changes are:
* Nova API (v2 and v3), to accept the certificate type as an option (defaulting to SSH if not provided)
* The nova.compute.
* nova.objects.
* Related database migration
* Nova metadata API to support an additional x509 content in nova.api.
* python-novaclient to add the optional keypair type option
Usage examples
Generating an x509 keypair via CLI and saving the private certificate locally (in PKCS#12 format):
nova keypair-add keypair1 --keypair-type x509
Importing an x509 public key certificate:
nova keypair-add keypair1 --keypair-type x509 --pub-key /path/to/
Note: the certificate type could be discovered by examining the content without requiring the user to provide it explicitly.
For backwards compatibility, omitting the certificate type results in a SSH certificate:
nova keypair-add keypair2 --pub-key /path/to/
equivalent to:
nova keypair-add keypair2 --keypair-type SSH --pub-key /path/to/
On the metadata side ssh keys and x509 keys are provided separately for backwards compatibility:
"public_keys": {"keypair2": "ssh-rsa AAAAB3...cyJvOQ== Generated by Nova\n"},
"x509": {"keypair1": "-----BEGIN CERTIFICATE-
Note: the -----BEGIN CERTIFICATE----- / -----END CERTIFICATE----- header and footer can be omitted
Blueprint information
- Status:
- Complete
- Approver:
- John Garbutt
- Priority:
- Medium
- Drafter:
- Alessandro Pilotti
- Direction:
- Approved
- Assignee:
- Alessandro Pilotti
- Definition:
- Approved
- Series goal:
- Accepted for kilo
- Implementation:
- Implemented
- Milestone target:
- 2015.1.0
- Started by
- Alessandro Pilotti
- Completed by
- John Garbutt
Related branches
Related bugs
Sprints
Whiteboard
Gerrit topic: https:/
Addressed by: https:/
Spec for Keypair support for X509 public key certs
Addressed by: https:/
Adds keypair type database migration
Addressed by: https:/
Adds x509 certificate keypair support
Addressed by: https:/
Adds keypair type nova-api
Not enough positive reviews on this code for it to make kilo-1, moving to kilo-2 --johnthetubaguy 17th December 2014
Addressed by: https:/
Revert "Adds keypair type database migration"
Addressed by: https:/
Adds keypair type database migration
Sorry, we have now hit the non-priority feature freeze for kilo. Please resubmit your spec for the L release. --johnthetubaguy 5th Feb 2015
Addressed by: https:/
Adds infrastructure for microversioned api samples
I think this is actually a priority item, I messed up here, approving for kilo-3 --johnthetubaguy 16th feb 2015
Addressed by: https:/
Adds cleanup on v2.2 keypair api and tests
Remaining patches (novaclient and a bug fix, but ideally part of this BP):
https:/
https:/
I have raised an RC1 bug to track this clean up:
https:/