Difference between revisions of "KMIPclient"

Revision as of 17:36, 1 November 2013

• Created: 12 July 2013
• Updated: 12 July 2013
• Contributors: Bill Becker,

Summary

The volume encryption blueprint [1] and specification [2] describe a key manager interface that allows different types of key managers to be used. This blueprint proposes to use the defined key management interface to communicate with a key manager that supports the OASIS Key Management Interoperability Protocol (KMIP). Any KMIP Key Manager that supports the defined interfaces will be able to manage the encryption keys used in the volume encryption feature. This approach of adding a KMIP client to OpenStack provides a secure key management option for the volume encryption keys while also allowing OpenStack integration into KMIP compliant enterprise key management systems which are already managing keys for other systems and applications.

System Architecture

As described in the Volume Encryption Specification [2], one goal was to support a key manager that implements OASIS KMIP. To support a KMIP key manager, a KMIP client needs to be implemented at the key manager interface. The below diagram is a copied from the volume encryption specification [2] with the addition of a KMIP Client for communication with an external key management appliance.

To add support for an external KMIP key manager, the following need to be implemented:

1. A KMIP client needs to be added to OpenStack.
2. A “Mock KMIP Key Manager” needs to be added to OpenStack to simulate the Key Management Appliance shown the diagram. This mock key manager should be used for testing purposes only and would be replaced with fully featured Key Management server or appliance that supports the same interfaces used by the Mock KMIP Key Manager.
3. A method to configure the KMIP client with parameters needed to allow communications with the key manager.

The following diagram shows the relationship between the 3 items defined in this KMIP Client blueprint, the existing key manager interface defined in the volume encryption blueprint, and an external KMIP key manager.

System Design

KMIP Client

The following diagram is copied from the Volume Encryption Specification [2] for convenience:

A KMIP client written in python would be implemented to support the KeyManager interface (i.e. it is the KMIPKeyManager shown in above diagram). Currently (29 Oct 2013) the KeyManager interface [3] defines five methods:

1. create_key( )
2. store_key( )
3. get_key( )
4. delete_key( )
5. copy_key( )

The above methods would be implemented using with the following equivalent operations defined in section 4 (Client-to-Server Operations) of the KMIP standard [6]:

1. create
2. register
3. get
4. destroy
5. 'get' followed by 'register'

Detailed design will map the parameters defined in the OpenStack key manager interface methods to the KMIP object types, template attributes, and attributes. For example, how do all the items in OpenStack create_key (below) relate to KMIP create operation which includes Object Type and Template-Attribute payloads?

def create_key(self, ctxt, algorithm='AES', length=256, expiration=None,**kwargs)

Mock KMIP Key Manager

The “Mock KMIP Key Manager” is modeled after the existing MockKeyManager [3] in complexity / functionality but also implements the KMIP server protocol. Like the MockKeyManager, the Mock KMIP Key Manager should not be used for anything but integration testing.

The Mock KMIP Key Manager would be python code. Similar to the MockKeyManager [3], it would implement the KMIP equivalents of create_key, store_key, get_key, delete_key, and copy_key.

KMIP Config

It is expected that the OpenStack KMIP client could be configured to communicate with any KMIP compliant key manager. The configuration parameters needed to establish secure communications to the KMIP Key Manager will be stored in the KMIP section of nova.conf config file. The type of parameters maintained in KMIP Config include {preliminary list which needs to be updated}:

• Network location (e.g. IPv4 address) of KMIP Key Manager
• Port number for KMIP Key Manager
• KMIP client authentication data: location of client SSL private key and certificate files.
• KMIP Key Manager authentication data: location of trusted CA cert file.
• Others TBD.

Authentication

As required in the KMIP Spec [6] and further defined in the KMIP Profiles [7], KMIP clients and server are mutually authenticated. As defined in the KMIP Profiles [7] and KMIP Usage Guidance [8], TLS will be used between the OpenStack KMIP client and KMIP Key Manager.

In addition, the key manager interface will pass a Keystone token to the KMIP client. This can be used by KMIP Key Manager as part of its authorization processing.

Transport

As required in the KMIP Spec [6] and further defined in the KMIP Profiles [7], KMIP clients and server takes place over a secure transport protocol.

Questions / Concerns

1. TLS Implementation – KMIP requires the use of a secure communications protocol (i.e. TLS). Does this TLS implementation need to be part of the KMIP Client code, or is it better / possible to leverage existing TLS functionality.
2. Authentication context token – The volume encryption key manager interface will pass a Keystone token to the KMIP client. Need to design how this can be consumed by KMIP Key Managers. It will likely differ based on the KMIP Key Manager being used, but it would be useful to provide an example of how it can be used within a KMIP Key Manager’s authorization systems.
3. Key Metadata / Attributes—Need to resolve the relationship between the a parameters defined in the key manager interface and the key metadata / attributes that are typically used by KMIP key managers. Are there needed parameters that are missing?
4. Real KMIP Key Manager testing – The Mock KMIP Key Manager is only intended for testing purposes. To promote interoperability, SafeNet can make a real KMIP Key Manager appliance (and/or virtual appliance) available over the internet for interoperability testing. Is this of interest?

Future Releases

Although this design adds a KMIP client to specifically support volume encryption keys, KMIP key managers typically have broad support for a variety of different key types and thus could be used to manage the diverse set of keys used within OpenStack. Based on the adoption rate of this solution, it is expected that this KMIP client design could be enhanced and/or replicated in future releases to allow other OpenStack features to communicate with enterprise key managers via the industry standard KMIP protocol.

References

[1] https://blueprints.launchpad.net/nova/+spec/encrypt-cinder-volumes Blueprint for Encryption of Attached Cinder Volumes.

[2] https://wiki.openstack.org/wiki/VolumeEncryption OpenStack Volume Encryption Specification

[3] https://review.openstack.org/30973 code for Create Key Manager Interface

[4] https://review.openstack.org/30976 code for Add Encryption Support for Volumes

[5] https://review.openstack.org/30974 code for related cinder change to Add Encryption Metadata to Volume Table.

[6] [KMIP-v1.1] Key Management Interoperability Protocol Specification Version 1.1. 24 January 2013. OASIS Standard. http://docs.oasis-open.org/kmip/spec/v1.1/os/kmip-spec-v1.1-os.html.

[7] [KMIP-Prof] Key Management Interoperability Protocol Profiles Version 1.1. 21 September 2012. Candidate OASIS Standard 01. http://docs.oasis-open.org/kmip/profiles/v1.1/cos01/kmip-profiles-v1.1-cos01.html

[8] [KMIP-G] Key Management Interoperability Protocol Usage Guide Version 1.1. 27 July 2012. OASIS Committee Note 01.http://docs.oasis-open.org/kmip/ug/v1.1/cn01/kmip-ug-v1.1-cn01.html.

[9] https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=kmip#technical OASIS KMIP TC web site.