Keypair support for X509 public key certificates¶
https://blueprints.launchpad.net/nova/+spec/keypair-x509-certificates
Introduction of X509 public key certificates keypair support in the Nova API.
Problem description¶
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, including PowerShell remoting.
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. This is limited by the lack of native availability of SSH on Windows.
Certificates can be generated by the user or by Nova (like for the SSH keypair case). Self-signed certificates are accepted.
Use Cases¶
End User will be able to connect to a Windows instance without requiring a password.
Like for the SSH keypair case, the use has the choice to generate the X509 certificate and pass the public X509 to Nova (recommended) or let Nova generate and return the certificate including the private key.
Project Priority¶
None
Proposed change¶
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, to accept the certificate type as an option (defaulting to SSH if not provided)
The nova.compute.api.KeypairAPI class to be able to generate and manage X509 certificates beside the existing SSH case
nova.objects.Keypair class to add a type property
Related database migration
Nova metadata API to support an additional x509 content in nova.api.metadata.base.InstanceMetadata()
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/PEM_encoded_public_certificate
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/SSH_pub_key
equivalent to:
nova keypair-add keypair2 –keypair-type SSH –pub-key /path/to/SSH_pub_key
On the metadata side ssh keys and x509 keys are provided separately for backwards compatibility:
“public_keys”: {“keypair2”: “ssh-rsa AAAAB3…cyJvOQ== Generated by Novan”}, “x509”: {“keypair1”: “MIIDaTC…ysk8w==n”},
Server metadata schema does not need changes: http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/schemas/v3/server_metadata.py
Alternatives¶
We are not worrying about the WinRM service certificate, as tools like cloudbase-init can generate a self signed certificate that works in a similar way to ssh host keys. Ideally the client would be told what certificate it needs to trust, but this will be left until we do the same for ssh host keys.
Data model impact¶
nova.objects.Keypair requires an additional string (VARCHAR(20)) type property, named “Type”. Initial possible values will be:
“ssh” “x509”
Default value during database migration will be “ssh”.
REST API impact¶
An optional extension named “os-extended-keypairs” will be added to “/v2/{tenant_id}/os-keypairs” providing the following:
GET /v2/{tenant_id}/os-keypairs
Will include in the response dictionary the key type “key_type”.
If the “os-extended-keypairs” extension is not present, only SSH keypairs will be returned.
POST /v2/{tenant_id}/os-keypairs
Will include an optional parameter “key_type” (xsd:string), with possible values “SSH” and “X509”, default value “SSH”.
The keypair schema definition will include “key_type” as well:
create = {
'type': 'object',
'properties': {
'keypair': {
'type': 'object',
'properties': {
'name': parameter_types.name,
'public_key': {'type': 'string'},
'key_type': {'type': 'string'},
},
'required': ['name'],
'additionalProperties': False,
},
},
'required': ['keypair'],
'additionalProperties': False,
}
server_create = {
'key_name': parameter_types.name,
}
Security impact¶
None
Notifications impact¶
None
Other end user impact¶
None
Performance Impact¶
None
Other deployer impact¶
None
Developer impact¶
None
Implementation¶
Assignee(s)¶
- Primary assignee:
cbelu
- Other contributors:
alexpilotti
Work Items¶
Nova feature implementation
python-novaclient support
Dependencies¶
The guest will need to employ an agent able to retrieve the certificates from the metadata and import them. Cloudbase-Init >= 0.9.6 is already supporting x509 certificates.
Testing¶
CI testing will be performed by the Hyper-V CI.
Tempest tests will be developed for this feature.
Documentation Impact¶
The Nova driver documentation for nova keypair API and CLI commands usage need to be updated.
References¶
Initial discussion (Juno design summit): https://etherpad.openstack.org/p/nova-hyperv-juno
Windows authentication without passwords in OpenStack http://www.cloudbase.it/windows-without-passwords-in-openstack/
An introduction to WinRM basics http://blogs.technet.com/b/askperf/archive/2010/09/24/an-introduction-to-winrm-basics.aspx
Cloudbase-Init on StackForge: https://github.com/stackforge/cloudbase-init