Open Stack

All of the main IaaS services are looking to bring in encryption of one form or another.

I believe that KMIP support for HSM integration at the Barbican backend is going to be very important to some deployers but the outstanding requirement has to be to solve the key management problem in a smart way that is easy to integrate with the rest of OpenStack and acceptable to the developers. To put it somewhat blunty, the less you have to learn to integrate, the less likely you are to cock it up. I see large-scale support for KMIP as a maturity feature in OpenStack that will add value for lots of organisations but at this point in development I believe going down the path of least surprise (for developers) is what's going to drive adoption and JSON/ReST is the way to do that.

-Rob



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: Tuesday, 23 July 2013 19:27
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] KMIP client for volume encryption key management

Thanks for your review and comments on the blueprint. A few comments / clarifications:


·         There are about a half dozen key manager products on the market that support KMIP. They are offered in different form factors / price points: some are physical appliances (with and without embedded HSMs) and some are software implementations.

·         Agreed that there isn’t an existing KMIP client in python. We are offering to port the needed functionality from our current java KMIP client  to python and contribute it to openstack.

·         Good points about the common features that barbican provides. I will take a look at the barbican architecture and join discussions there.


Thanks,
Bill


From: Jarret Raim [mailto:jarret.raim at RACKSPACE.COM]
Sent: Friday, July 19, 2013 9:46 AM
To: OpenStack Development Mailing List
Subject: Re: [openstack-dev] KMIP client for volume encryption key management

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.





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.