Open Stack

I'm not sure that I agree with this direction. In our investigation, KMIP is a problematic protocol for several reasons:

  *   We haven't found an implementation of KMIP for Python. (Let us know if there is one!)
  *   Support for KMIP by HSM vendors is limited.
  *   We haven't found software implementations of KMIP suitable for use as an HSM replacement. (e.g. Most deployers wanting to use KMIP would have to spend a rather large amount of money to purchase HSMs)
  *   From our research, the KMIP spec and implementations seem to lack support for multi-tenancy. This makes managing keys for thousands of users difficult or impossible.

The goal for the Barbican system is to provide key management for OpenStack. It uses the standard interaction mechanisms for OpenStack, namely ReST and JSON. We integrate with keystone and will provide common features like usage events, role-based access control, fine grained control, policy support, client libs, Celiometer support, Horizon support and other things expected of an OpenStack service. If every product is forced to implement KMIP, these features would most likely not be provided by whatever vendor is used for the Key Manager. Additionally, as mentioned in the blueprint, I have concerns that vendor specific data will be leaked into the rest of OpenStack for things like key identifiers, authentication and the like.

I would propose that rather than each product implement KMIP support, we implement KMIP support into Barbican. This will allow the products to speak ReST / JSON using our client libraries just like any other OpenStack system and Barbican will take care of being a good OpenStack citizen. On the backend, Barbican will support the use of KMIP to talk to whatever device the provider wishes to deploy. We will also support other interaction mechanisms including PKCS through OpenSSH, a development implementation and a fully free and open source software implementation. This also allows some advanced uses cases including federation. Federation will allow customers of public clouds like Rackspace's to maintain custody of their keys while still being able to delegate their use to the Cloud for specific tasks.

I've been asked about KMIP support at the Summit and by several of Rackspace's partners. I was planning on getting to it at some point, probably after Icehouse. This is mostly due to the fact that we didn't find a suitable KMIP implementation for Python so it looks like we'd have to write one. If there is interest from people to create that implementation, we'd be happy to help do the work to integrate it into Barbican.

We just released our M2 milestone and we are on track for our 1.0 release for Havana. I would encourage anyone interested to check our what we are working on and come help us out. We use this list for most of our discussions and we hang out on #openstack-cloudkeep on free node.


Thanks,
Jarret




From: <Becker>, Bill <Bill.Becker at safenet-inc.com<mailto:Bill.Becker at safenet-inc.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, July 18, 2013 2:11 PM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: [openstack-dev] KMIP client for volume encryption key management

A blueprint and spec to add a client that implements OASIS KMIP standard was recently added:

https://blueprints.launchpad.net/nova/+spec/kmip-client-for-volume-encryption
https://wiki.openstack.org/wiki/KMIPclient


We’re looking for feedback to the set of questions in the spec. Any additional input is also appreciated.

Thanks,
Bill B.

The information contained in this electronic mail transmission
may be privileged and confidential, and therefore, protected
from disclosure. If you have received this communication in
error, please notify us immediately by replying to this
message and deleting it from your computer without copying
or disclosing it.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130719/9d73daa7/attachment.html>